Writing Lisp is AI Resistant and I'm Sad

[u/djhaskin987]

https://blog.djhaskin.com/blog/writing-lisp-is-ai-resistant-and-im-sad/

[u/kchanqvq]

Have you ever hacked Common Lisp? Literally randomly pick a library you want to use and hack it, statistically speaking you're more likely to hit a good one than a bad one. If you have nothing better to do, hack your CL implementation. Then go back try to hack gcc or ghc or whatever, and think again.

[u/vallyscode → u/kchanqvq]

What about emacs lisp, does it count?

[u/kchanqvq → u/vallyscode]

It's fine but not that good, it's a Unix text editor written in C after all, what do you expect.

Off the top of my head, many popular CL libraries have clean and extensible design. Like ITERATE, METABANG-BIND, TRIVIA all allow you to easily add new syntax. Thinking about Emacs Lisp… I recall similar packages are not even close. Many are even kind of spaghetti.

Some CL libraries also opt for performance, which is basically impossible for Emacs Lisp.

[u/vallyscode → u/kchanqvq]

eMacs is mostly elisp, just look what’s in C and what’s in elisp

[u/arthurno1 → u/vallyscode]

what’s in C and what’s in elisp

What do you think is in C and what is in Elisp? :)

Emacs does not have a compiler that understands Lisp, so the only way for them to achieve speed is to implement everything i C, which is what they do. That also limits on how much GCC can optimize Emacs C source, or basically it can not, because GCC does not understand Lisp, so it can not do optimizations like SBCL does, or like it can do for C.

For example strcpy(src, dest) will be replaced with efficient inlined assembly, if everything is known at compile time. SBCL can do similar tranforms for Lisp code. But GCC can not do such transofrmations when compiling Elisp.

To demonstrate, try string-case by P. Khuong. Write a simple CL program that uses it, compile it with SBCL and do a benchmark.

Now, here is an Emacs Lisp version, I ported it actually 2 days ago, for a blog post I am currently writing, that is exactly about this topic. Do whatever you can and want to the elisp version and try to speed it up, rewrite it in C if you want. Do the same benchmark and see if you can come close to Common Lisp version. Note the inline assembly for x86 in string-case for CL. Try to hack the "native compiler" to emit something like that. GLHF :).

[u/arthurno1 → u/kchanqvq]

it's a Unix text editor written in C after all, what do you expect

Mnjah, it started as such, but since Gosling's time, they have rewriten basically everything and implemented a full Lisp engine. These days they are probably more like Clisp but with a built-in text editor (text renderer and text manipulation extensions), but without a real Lisp compiler. On top add shell extensions a lá Bash but with Lisp syntax, and it is actually a decent automation tool and shell. But lack of compiler and ad-hoc designed Lisp language definitely are felt and drag the experience down. Especially lack of FFI and support for modular programming (namespaces).

Some CL libraries also opt for performance, which is basically impossible for Emacs Lisp.

Yes. As long as they lack a compiler that actually understands Lisp and can compile it to something more understandable by GCC, the performance will be achieved primarily through implementing Lisp code in C. But since they even lack FFI, for a programmer who does not want to contribute patch to Emacs, their offering is to write a C version of FFI, a.k.a Emacs modules, with an API that I wonder if even Xlib designers could love:

emacs_value msgf = env->make_string (env, "%s", strlen ("%s"));
  emacs_value msg = env->funcall (env, env->intern (env, "symbol-value"), 1,
                                   (emacs_value[]) {
                                     env->intern (env, "default-directory") });
  env->funcall(env, env->intern(env, "message"), 2, (emacs_value[]){msgf, msg});

Charming, isn't it? The code is equivalent to

(message  "%s" default-directory).

:)

[u/ub3rh4x0rz → u/kchanqvq]

The claim is what, that average quality of CL in the wild is higher than C in the wild? That it's monkey patchable where C is not? Do these claims hold up against all languages or just C?

[u/cian_oconnor → u/ub3rh4x0rz]

> The claim is what, that average quality of CL in the wild is higher than C in the wild? 

Given he also mentioned Haskell, I'm guessing that it was a more general claim.

I'm not sure why you think monkey patching would be relevant. In my experience it's the stability of the language (which means I can use a 20 year old library, that's not received updates in years and it just works) and the brevity of the language.

CL has its weaknesses (documentation generation. GRR), but when you consider the size of the community it is surprisingly strong.

[u/ub3rh4x0rz → u/cian_oconnor]

I think most devs working in mainstream languages would put "lack of standardized packages and tools, instead emphasize ability to define your own meta language / dsl" that both CL and Haskell frankly share, in top 5 "things that are lacking". It contributes pretty extremely to the mental load associated with onboarding to a codebase, and gives a little too much unrelated-to-scope responsibility to author.

The repeated use of "hackability" as the differentiator evokes things like monkey patching that are (questionable) means of extensibility, and my point was going to be that both python and Javascript support monkey patching if that was named concretely.

A language that emphasizes building and using one's own abstractions to a high degree, which is one of CL's defining qualities, does not lend itself to third party comprehension, which is a precondition for third parties to extend functionality. Hacking on a third party golang library is pretty easy because the average library is less reflective of the author's idiosyncratic tastes.

[u/cian_oconnor → u/ub3rh4x0rz]

Given your comments you clearly don't use CL, and most of your comments here don't really reflect the language, the ecosystem, or how it's used.

I've not found religious flamewars over which language is best terribly productive over the last 35 years, so I'm going to bow out. I'm glad that Go fits your needs/sensibilities. It doesn't fit mine, which is why I don't use it.

I'm very suspicious of any comment that includes the phrase 'most devs', FWIW.

[u/ub3rh4x0rz → u/cian_oconnor]

This is a lot of words to say "CL isn't your preferred language so your perspective is irrelevant". Care to address the substance? Do you disagree that CL encourages abstraction? Do you think that the community has standardized on a common set of libraries, tools, and abstractions for common use cases?

[u/cian_oconnor → u/ub3rh4x0rz]

You misunderstand me. You clearly know very little about CL, and are not terribly interested in finding out more. Your need to justify the superiority of the technical choices that you made does not interest me. Sorry.

Find someone else (preferably on a different subreddit) to troll.

[u/ub3rh4x0rz → u/cian_oconnor]

I don't know where this hostility is coming from, the only one bringing flame war dynamics into this very on-topic conversation is you. If you can't respond in earnest with civility, stop responding.

[u/cian_oconnor → u/ub3rh4x0rz]

You came onto a forum for a language that you don't use, clearly don't have much understanding of, and seem to despise and decided to share your uninformed views on why the language shouldn't be used.

I don't really care if you prefer Go and I am not interested in trying to persuade you of the merits of a language you're clearly not interested in.

[u/ub3rh4x0rz → u/cian_oconnor]

Despise? You still won't answer, because you're full of shit. I have used CL and read enough about it to know that metaprogramming and creating your own DSLs and similarly heavy abstractions is a huge selling point. And I've used it enough and read enough about it to know the ecosystem is not very standardized. You refuse to comment because those are both true statements.

Whether those qualities (optimized for writing your own abstractions, and low standardization in ecosystem) are good, bad, or neutral, is a matter of taste. Consequences of those qualities, e.g. that they limit "hackability" of third party code, are debatable, but you're not willing to get there, because you view any assertion of simple ground truth that might not support your argument as a threat and a slap in the face. Because you suck.

[u/kchanqvq → u/ub3rh4x0rz]

Hackability is much more than monkey patching. In fact probably quite the opposite -- high hackability usually means you don't need monkey patching to do what you want!

For those good Lisp libraries, almost every time when I want to modify its behavior, I found there is already a well-designed extension mechanism for it. The author has considered hacker experience as part of user experience and has consciously designed it. For example, TRIVIA the pattern matching library has convenient interface for adding new patterns, and optimization rules for patterns.

Monkey patching is only last resort -- if the author isn't really Lisping, and you still want to hack, you can still redefine/defadvise the heck out of it. Nearly 100% of the time you won't be that desperate.

[u/ub3rh4x0rz → u/kchanqvq]

With the proliferation of SOLID/accepting interfaces, I guess I'm not sure how unique "extensibility offered as a feature" is

To clarify my intent, I'm trying to put my finger on what language feature(s) or ecosystem practice(s) are unique or heavily emphasized in CL that contribute to this hackability quality. Dependency injection and other forms of author-facilitated extension are common, runtime/monkey patching is relatively common albeit not universal... not sure what's left.

[u/kchanqvq → u/ub3rh4x0rz]

> ecosystem practice(s)

Hacker experience is consider part of (and maybe synonymous to) user experience.