As a Common Lisp developer, the intro about Lisp strikes me as sort of mostly(?) true.
I would say in my experience we do actually "compile and execute" code, we can just do this incrementally and with less context switching because of the described workflow. But quite often there are in fact separate compile and run steps, it's just not at the whole program level (say, compile a function and run it or a calling function).
And despite how often it's shown off as a strength, redefining code during actual execution isn't quite that common, I think. Yes, it is done sometimes, but lots of programs don't really fit that paradigm in the first place. It can work well for e.g. some games or long running servers.
As for working in an image without source code: this seems like a terrible idea. You might do this for trivial, one off experiments, but in general you benefit from writing out and organizing your code early. I'm not even aware of a particularly easy or clean way to write out source code from an image as described. It could be done, but all the ways I can think of sound like more of a pain or mess than anything. Could just be my experience or I'm missing some neat feature of a commercial Lisp or something.
i have learned a lot of interesting facts about haskell and lisp from this post. those facts make me want to run screaming away from trying to use either of them to develop software. My time with Haskell made me a better programmer and I bet that LLMs made some of the documentation more intelligible, but...
I have other reasons - mostly hiring competent engineers that deeply undertand the language. I can hire a competent SpringBoot engineer who can "fill out the form" and have a fast-enough API ready in a few days. Will it be beautiful and elegant? Probably not. Will it take traffic and get the data from the producer into a database reliably? Most likely.
From my time with Haskell, I learned to REALLY think about types. Like, REALLY. Having a type doc above every function that describes a curried path, is really cool. It made OCaml documentation (which I consider among the worst) make sense. (No shade at OCaml as a language. I LOVE it. But their docs aren't gonna win any awards)
What in particular makes you want to run away? I have found that the some what cliched(but true) comment that type signatures are mostly what you need for documentation even with heavy transformer code. I am some what confused by the post in question saying their repl experience in haskell was bad, I found the repl very powerful and worked well. The things I disliked of haskell the most was the package management, templating, issues around lazy eval, program start up time, program performance (particularly memory size) and some library's being overly based on some abstract mathematical model for little benefit and lots of cost and less flexibility and template haskell again because I really hate it. working on a common lisp project at the moment and it's quite nice thought he package manager story is a little bad in the very opposite direction to haskell in that it's too bare bones (quicklisp) but it's pretty easy to just git clone repos you want and use asdf to load them (asdf is a little weird to start but when you understand the whole load system repo stuff and central-registry variable your good to go and build what ever you want around it.
Another annoying thing with common lisp is when macros badly expand that can be tricky to debug.
You may already know of these, but for others curious:
I'm also not a huge fan of quicklisp, though bundles[0] made it a little more bearable for me. You may also consider vend[1], ocicl[2] (heavily AI-assisted recently), or qlot[3].
For macroexpansion, SLIME and SLY have macrostep functionality that lets you expand macros in place, which has helped me immensely on more than one occasion, though you can also manually expand with macroexpand.
Have you even seen R? Jupyter notebooks? The above sounds like a level of insanity beyond that.
The problem with checking things at runtime is that it’s an ever-moving target. Changed this? Now that other thing is out of sync. Changed that? Now the first thing is gone, and it came from far away so you can’t get it back in this session.
Most lisp systems get recompiled from sources, and while they support dumping an image, that's essentially an optimization. Emacs for example makes an initial dump, then loads the rest from .el files, and the base image remains static (you can dump a new image from a running emacs, but it's always been fiddly). The only thing left that I know of that's image-first is Smalltalk, and not even all implementations.
I find it so fascinating how many programmers proudly declare how they don't use any IDE when incredibly sophisticated tools like solidworks or Synopsis are universally used in engineering
The language dominates the tooling. Real C programmers probably can't imagine doing real programming without gdb and valgrind. Real Java programmers probably can't imagine doing real programming with gdb and valgrind.
As a Common Lisp developer, the intro about Lisp strikes me as sort of mostly(?) true.
I would say in my experience we do actually "compile and execute" code, we can just do this incrementally and with less context switching because of the described workflow. But quite often there are in fact separate compile and run steps, it's just not at the whole program level (say, compile a function and run it or a calling function).
And despite how often it's shown off as a strength, redefining code during actual execution isn't quite that common, I think. Yes, it is done sometimes, but lots of programs don't really fit that paradigm in the first place. It can work well for e.g. some games or long running servers.
As for working in an image without source code: this seems like a terrible idea. You might do this for trivial, one off experiments, but in general you benefit from writing out and organizing your code early. I'm not even aware of a particularly easy or clean way to write out source code from an image as described. It could be done, but all the ways I can think of sound like more of a pain or mess than anything. Could just be my experience or I'm missing some neat feature of a commercial Lisp or something.
i have learned a lot of interesting facts about haskell and lisp from this post. those facts make me want to run screaming away from trying to use either of them to develop software. My time with Haskell made me a better programmer and I bet that LLMs made some of the documentation more intelligible, but...
I have other reasons - mostly hiring competent engineers that deeply undertand the language. I can hire a competent SpringBoot engineer who can "fill out the form" and have a fast-enough API ready in a few days. Will it be beautiful and elegant? Probably not. Will it take traffic and get the data from the producer into a database reliably? Most likely.
From my time with Haskell, I learned to REALLY think about types. Like, REALLY. Having a type doc above every function that describes a curried path, is really cool. It made OCaml documentation (which I consider among the worst) make sense. (No shade at OCaml as a language. I LOVE it. But their docs aren't gonna win any awards)
What in particular makes you want to run away? I have found that the some what cliched(but true) comment that type signatures are mostly what you need for documentation even with heavy transformer code. I am some what confused by the post in question saying their repl experience in haskell was bad, I found the repl very powerful and worked well. The things I disliked of haskell the most was the package management, templating, issues around lazy eval, program start up time, program performance (particularly memory size) and some library's being overly based on some abstract mathematical model for little benefit and lots of cost and less flexibility and template haskell again because I really hate it. working on a common lisp project at the moment and it's quite nice thought he package manager story is a little bad in the very opposite direction to haskell in that it's too bare bones (quicklisp) but it's pretty easy to just git clone repos you want and use asdf to load them (asdf is a little weird to start but when you understand the whole load system repo stuff and central-registry variable your good to go and build what ever you want around it.
Another annoying thing with common lisp is when macros badly expand that can be tricky to debug.
You may already know of these, but for others curious:
I'm also not a huge fan of quicklisp, though bundles[0] made it a little more bearable for me. You may also consider vend[1], ocicl[2] (heavily AI-assisted recently), or qlot[3].
For macroexpansion, SLIME and SLY have macrostep functionality that lets you expand macros in place, which has helped me immensely on more than one occasion, though you can also manually expand with macroexpand.Sounds genuinely horrible to program this way.
> A Lisp programmer does not need to …
Have you even seen R? Jupyter notebooks? The above sounds like a level of insanity beyond that.
The problem with checking things at runtime is that it’s an ever-moving target. Changed this? Now that other thing is out of sync. Changed that? Now the first thing is gone, and it came from far away so you can’t get it back in this session.
Most lisp systems get recompiled from sources, and while they support dumping an image, that's essentially an optimization. Emacs for example makes an initial dump, then loads the rest from .el files, and the base image remains static (you can dump a new image from a running emacs, but it's always been fiddly). The only thing left that I know of that's image-first is Smalltalk, and not even all implementations.
I find it so fascinating how many programmers proudly declare how they don't use any IDE when incredibly sophisticated tools like solidworks or Synopsis are universally used in engineering
The language dominates the tooling. Real C programmers probably can't imagine doing real programming without gdb and valgrind. Real Java programmers probably can't imagine doing real programming with gdb and valgrind.
Off topic but the way the four “program…” words line up on an iPhone is truly mesmerizing.
They are using Emacs that's basically an IDE.