4xel

> Paren issues with Clojure probably mean your functions are too long? I like to keep mine down to 8-10 lines or less when possible, keep them flat and composable, use threading macro and then transducers for performance.

This is a separate issue. You give great advice for both humans and LLMs, and anything in between, but the fact that it misses parens at all demonstrates it is not reasoning at the AST level, at least not directly, and that's the point the person your replying to is making.

An hypotetical NN trained to produce valid AST would most likely never get it wrong, it would likely even be given the whole stack of opened context as its input to generate the next token, not just the preceding text tokens, not unlike humans have with indentation and parens highliters. At this point it would be pretty hard to miss a paren.

> > Homoiconicity and the AST

It's a purely theoretical and speculative advantage as of now. Human lisper think in AST, that's something powerful, and it's reasonable to assume an AI could too, with benefits. But LLMs simply don't; not only they will occasionally mismatch parens, but they will dig themselves in a pit when asked to fix it. Stronger models miss far fewer parens, but that's most likely that they adapt better, not that they think in s expressions ASTs. But we could totally imagine transformer producing directly ASTs, and lisp is probably the best first target for that.

I've found macros and live programming to be much of the same: it'll do it when asked to, but is not particularly natural or apt at it. They can use macros well, but will rarely choose to write the correct macro when needed.

Live programming feel particularly ill-suited: multiplying small request with an accumulating context sounds like a sure fire way to explode your token budget. It does wonder for humans because we're able to compress our "context" on the fly. Context caching may mitigate all or most of it, but then it make compressing context less worthwhile. As much as I dislike it, LLMs are punch-card programs suited punch-card programming (write/read all in one go, then compile and execute); his entire training set is arguably punchcard, even from live programming languages.

> shouldn't we have the LLM generate Erlang?

Unironically a good idea

Lisp debuggers are uncommonly powerful, but there's more to "living systems" than debuggers. I suck at using debugging tools, lisp or otherwise, yet I still love the living system aspect of Lisp or OCaml.

In mainstream languages, the closest thing to the "living system" part of lisp that I personally grasp and love is not debbuggers; it's Jupyter Notebooks, SQL sandboxes in DBMS UIs, and scripting, as in shell scripting. Still, given the choice, I prefer the Emacs+lisp experience over these great tools.

Also, live programming is not something lisp overspecialize in, like could be argued for most of the aforementioned tools. Rather, it incorporates it seamlessly. In visual studio, I can run a program line by line or with breakpoints. In lisp, I can select which s experession(s) I want to compile or execute, while an LLM agent is connected to the same image and doing stuffs in the background.

I do not merely get any single potential benefit of dynamic languages, I get all of them at once, even when working on a source file perfectly suited for punchcard programming (read compile execute).

This really frustrates me, because it shouldn't be much harder to train a generative transformer models to be aware not just of previous tokens but also programming context, that is the current pile of open parens and their associated verb. Lisp is obviously the best place to experiment this idea, but other programming languages are full of braces which need closing too.

Wholheartedly agree! Even as someone who loves a challenge, has a high opinion of themselves, and knew would love LISP, I postponed diving into it longer than I wish I had, on the mistaken assumption it would be pretty hard.

Still, I don't think it's wrong to say LISP is for the elite. It is harmful when it's implied it's only for the elite, but being for the elite is not exclusive with being easy to learn, or being good for newcommers.

Heck, lisp minimal syntax is probably what bridges the two, and it (s expression, and lack of m expressions) was explicitly petitioned for by early lispers, for reasons which likely make them a similar elite than present day lisp enjoyers.

Likewise, appeal to the masses does not equate ease of learning, or even anti-elitism. It certainly is a common marketing point, but familiarity is what really matters. Emacs has never been so good, Microsoft Office is a good decade or two deep in enshittification, and guess what modern day secretaries use?

While I agree with the conclusion, I don't agree with all the examples given.

> Invariant: From this point on the array’s length must be 3N + 1 for some integer N.

Invariant can be checked by code, and they definitely should if your language allows constraints or asserts (checked at comptime or ran in test and debug mode)

> We use simple brute force here because instances are guaranteed to be small (see guard above).

The guard above probably conveys the information already.

> Limit each request to one day’s data; otherwise, we won’t get 1-minute resolution.

This could be a benchmark, though I wouldn't be unhappy to read this as a comment, and I wouldn't care if there was no benchmark.

A couple others could be in a separate technical doc rather than in comment. I'm on the fence about it, a bit more on your side, but there are ways and places to express intent outside of the source code that the "no comments" crowd may argue for.

As for the python example, it's a great illustration of your point, there are many comments, but it's hard to remove any. Still:

# Weights must be non-negative integers. and # The distribution must have a positive total weight.

Can be discarded without losing anything: the parameter validation they comment is already transparent, and even includes natural language in the error message, describing what happens why.

Some other comments describe the what rather than the why, but the code it refers to is dense enough that it's warranted.

I'm confused, what emacs do you have in mind? For me, emacs is a lisp machine, hackable live, M-. all the way down, that kind of things, that's the whole point (again, subjective opinion, and I'm interested in yours).

What language do you have in mind?

If you're worried about performance, Common Lisp is a compiled language. It's about the best performing dynamic language there is, and not too far behind Zig, Rust and the likes.