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?

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!

eh, I think Haskell admits programming-by-discovery more than that but part of the dream of affordances-and-DSLs is the whole "write your whole program in the REPL" tale that I've heard about re: lisp, and Haskell is not that. (I've dabbled in common lisp and scheme and never found it, though)

So it's not actually make-your-program-in-the-REPL. It's that you write code, reload what you edited, and then interactively test in the REPL. You can build up confidence in your program piece by piece, as you build it (although this can hurt you by disincentivizing formal unit/integration) tests.

In both Lisp and Smalltalk you can have an exception, inspect the environment in the moment the exception occurred, interactively inspect everything, WRITE THE CODE THAT MAKES IT SO THAT CAN'T HAPPEN ANYMORE, patch the running system, and continue execution.

i don’t think that’s true, more that people are inclined to take that approach by virtue of what attracted them to the language. you can dynamically type whatever you want or stash evil things behind deferred evaluation if you don’t want to be rigorous.

Yes. What I'm saying is that those values define the affordances of the language and therefore what is easy, what is difficult, and what isn't permitted. The design of a language changes the things you are most likely to write!

Actually one of the problems with AI is that it makes it possible for people who do not value rigor to enter spaces where that rigor is a part of the social construct where previously they would have been warned off by language design that does not optimize for what they care about.