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 haven't used Lisp but I've used another environment that was heavily image based (Frontier). The runtime ability to modify things sounds super neat but in my opinion it leads to disaster. It is not a weakness that we have a lot of tech built on a concrete specification of the initial state of the system and very careful control over where data and the modified versions of that data live. It is hard-won experience that it is a good way to build robust systems. "Reboot & pray" isn't just an accident, it's a legitimately good way to set up a system.
Some of you may object to the idea that we are super careful with data and modifications to it. I know where you are coming from... however, compared to an image-based system, the modern world is in fact super careful! To the extent that you think we are still not careful enough, that leads you even farther from wanting an image-based system.
If you conceive of a system as the full state space of everywhere it can go, the vast, vast, vast majority of systems have pathological places in it. It is very hard to get them all out. It is advantageous to have a button that says "restart this system from the initial state", and to push it often to make sure it continues to work, even if you're not thinking of it this way. By contrast, image-based systems have the tendency to either 1. get into a bad place in the state space and then the user has no way back out or 2. accidentally create a scenario in which there is no way to bring the system up from scratch anymore, which includes things like "giving the system to someone else to start their own work up".
Sure, it's a good idea to minimize the need to hit the reset button. But you don't really want to give it up entirely.
There are a variety of ways of improving the image-based system. Most, perhaps all of the practical ones, involve basically removing the image-based nature of it and moving closer to the systems we all work with today.
Gawd, that image-based approach to programming has never been mainstream because it creates a terrible mess.
Look at the nightmare notebooks you get from data scientists working in Python where they want to have their answers baked into a notebook that they can show to people and don't realize they need to separate code and data in version control and have a script you can run from top to bottom if they want to put their skills on wheels.
To be honest given the amount of structural obliteration you get out of GHC, image-based development sounds like a really bad idea. Haskell is such a weird and unintuitive language to understand from a systems perspective, because it's almost like you're restricted to writing macros for a language that you never directly see or interact with. The transformation from your source code to what the compiler spits out is can be highly non-local and unpredictable, even before you start introducing things like custom rewrite rules.
To me, I think the smart way to work with Haskell is the exact opposite of iteration. Work it out on paper, refine it, find the algebraic rules for it, refine it some more, and then start writing code once you know exactly what you're doing. I think giving in to the temptation to Just Start Writing Code is how you end up with opaque type spaghetti. That's just my feelings on it.
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.
Thank you for this, I knew only of ocicl and have only been using macro expand in the repl, will have to try macrostep.
My work flow for packaging is very hacky at the moment, I have sbcl install on the host but mostly for developing I run in a podman container and download repos of libraries as I need them and then mount them in a volume and also mount a link farm to load all the asdf systems and that is set up by the initialization script and starts swank and any other initialization needed. probably ocicl does a lot of what I want but for a particular things I was doing I was I also wanted to modify a library so it evolved like this it might be a little insane but new to common lisp development so might be bad.
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 once inherited an APL system which was just an image. I didn't know where to start trying to get function definitions out of it and into some kind of version control and eventually ported to something else. I'm interested to know how much better it would have gone with LLMs.
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
Completely agree, having worked with engineers and scientists for a large part of my career.
Programming is still in this goofy phase as a profession/industry where lots of practitioners interpret suffering and complexity and difficulty as signals of underlying quality.
There are still large numbers of programmers who see advances in human-computer interaction and tools as basically childish, because what matters to them is the feeling of machismo they get while programming, rather than whether their efforts make their users more successful.
See the pushback against IDEs (as you said), syntax highlighting (“syntax highlighting is for children”), Rust (“_I_ know how to manage memory, everyone else is an idiot who needs to git gud”), types generally (“_I_ don’t make type errors”). Even high level languages and garbage collection were met with similar derision when they were going mainstream. There are so many examples of this throughout the history of programming.
If something is hard to do, or resulted in something impressively complex rather than something underwhelmingly simple, it must be good.
Basically, we’re still a very immature profession and it’ll take time before we shed the “the most important thing about programming is that I get to be a wizard” stuff. The users care that the bridge doesn’t fall down when they drive over it. The users don’t care whether designing the bridge made me feel powerful and wizardly because I used a crayon rather than Solidworks.
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.
every tool present in an IDE is available elsewhere. it’s not that the IDE-avoidant aren’t using sophisticated tools, they just aren’t using them packaged up in a single application.
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.
Some of you may object to the idea that we are super careful with data and modifications to it. I know where you are coming from... however, compared to an image-based system, the modern world is in fact super careful! To the extent that you think we are still not careful enough, that leads you even farther from wanting an image-based system.
If you conceive of a system as the full state space of everywhere it can go, the vast, vast, vast majority of systems have pathological places in it. It is very hard to get them all out. It is advantageous to have a button that says "restart this system from the initial state", and to push it often to make sure it continues to work, even if you're not thinking of it this way. By contrast, image-based systems have the tendency to either 1. get into a bad place in the state space and then the user has no way back out or 2. accidentally create a scenario in which there is no way to bring the system up from scratch anymore, which includes things like "giving the system to someone else to start their own work up".
Sure, it's a good idea to minimize the need to hit the reset button. But you don't really want to give it up entirely.
There are a variety of ways of improving the image-based system. Most, perhaps all of the practical ones, involve basically removing the image-based nature of it and moving closer to the systems we all work with today.
Look at the nightmare notebooks you get from data scientists working in Python where they want to have their answers baked into a notebook that they can show to people and don't realize they need to separate code and data in version control and have a script you can run from top to bottom if they want to put their skills on wheels.
To me, I think the smart way to work with Haskell is the exact opposite of iteration. Work it out on paper, refine it, find the algebraic rules for it, refine it some more, and then start writing code once you know exactly what you're doing. I think giving in to the temptation to Just Start Writing Code is how you end up with opaque type spaghetti. That's just my feelings on it.
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)
Another annoying thing with common lisp is when macros badly expand that can be tricky to debug.
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.My work flow for packaging is very hacky at the moment, I have sbcl install on the host but mostly for developing I run in a podman container and download repos of libraries as I need them and then mount them in a volume and also mount a link farm to load all the asdf systems and that is set up by the initialization script and starts swank and any other initialization needed. probably ocicl does a lot of what I want but for a particular things I was doing I was I also wanted to modify a library so it evolved like this it might be a little insane but new to common lisp development so might be bad.
> 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.
Programming is still in this goofy phase as a profession/industry where lots of practitioners interpret suffering and complexity and difficulty as signals of underlying quality.
There are still large numbers of programmers who see advances in human-computer interaction and tools as basically childish, because what matters to them is the feeling of machismo they get while programming, rather than whether their efforts make their users more successful.
See the pushback against IDEs (as you said), syntax highlighting (“syntax highlighting is for children”), Rust (“_I_ know how to manage memory, everyone else is an idiot who needs to git gud”), types generally (“_I_ don’t make type errors”). Even high level languages and garbage collection were met with similar derision when they were going mainstream. There are so many examples of this throughout the history of programming.
If something is hard to do, or resulted in something impressively complex rather than something underwhelmingly simple, it must be good.
Basically, we’re still a very immature profession and it’ll take time before we shed the “the most important thing about programming is that I get to be a wizard” stuff. The users care that the bridge doesn’t fall down when they drive over it. The users don’t care whether designing the bridge made me feel powerful and wizardly because I used a crayon rather than Solidworks.