Post

I've been off-and-on smitten by this idea, which I associate mostly with lisp enthusiasts (affectionate), that if you just had the right affordances around abstractions and DSLs programming would be magic after writing Haskell professionally for a few years I'm depressed, systems are too wide

I mean not magic, but the right affordances can create magic. TBH I think the experience of writing Lisp or SmallTalk is the closest thing to vibecoding that isn't vibecoding?

Haskell isn't like this, Haskell has this rigorous, mathematical, "really consciously do a lot of design thinking up front" kind of culture, and Lisp, SmallTalk, and other "weird" languages like FORTH and APL, are the TOTAL OPPOSITE of that!

The goal of these languages is to be able to rapidly iterate, to implement both programs and abstractions very quickly. Ideally that there IS no edit-compile-test cycle because editing and testing and compiling are continuous and intermingled.

This makes lisp kind of the anti-vibecoding—code is everpresent in the thinking process, rather than absent, but they're using different technologies to achive the same goal: raising the level of abstraction to allow for faster prototyping and iteration, more malleable software, at the cost of rigor

Sometimes this is a good trade! If you don't know what you'll need your software to do tomorrow, Lisp can be amazing. Emacs may have its many (large, awful, exceedingly egregious) warts, but that malleability has allowed it to adapt successfully to the changing needs of developers for over 40 years!

(despite its historical baggage I actually think Emacs is very well-positioned for the LLM era. It is one of the only editors where there is, truly, literally an API for everything.)

But, and I know this is heretical, not all software should be written in Lisp! Many people have difficulty reading and writing it, and also, different points on the language design curve have advantages for more permanent software.