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.
I don't object to any of this. "Restart this system from initial state" is quite a bit more common than people imagine in CL. I was hinting at it perhaps being even more common than image-based development, though don't quote me on that. I personally don't even really create Lisp images in dev (save for creating executables that I don't then further modify, which are technically images in SBCL).
Incremental runtime modification is great for development, but I very frequently restart (from sources) every so often, and certainly at least before deployment to verify everything is working as expected. Sometimes because it's completely necessary, sometimes for my own sanity.
For production, I think it's a very "neat" thing to be able to do and I've heard some great stories (no personal experience), but it's definitely a foot gun if not used very carefully.
99% of the time, you simply write the code or change in the sources first, then compile/run it in the runtime.
If you're modifying the runtime directly at the REPL without having sources, good luck? or you don't really care about persisting those changes. CL has pretty good introspection, so you could look at the source expression of a function defined at the REPL for example, if you really wanted to recover something (and happened to put the change in a function first), but this isn't always reliable.
I also found the description of Lisp development weird, as if it's a second-hand repetition of someone else describing watching a Lisp developer in action.
The workflow I always use is to write code in my editor and use a keyboard shortcut to evaluate it. Typing directly into the REPL is for one-off state updates, inspection, experiments, and similar throwaway code.
Even the original MIT Lisp Machine was designed around editing source files, there were "compile the current function" keybindings and menu options in the version of Emacs for it.
You could also type an individual function into the repl then pretty-print it to a file but that typically expands out any read macros that you may have used.
You could type something in to the repl then add it to a file later.
There was a structure editor that worked on the s-expression of a function, including any comments as they were represented as a special form within that structure.
I am not a Lisp developer by trade, but I accidentally made an interpreted Lisp as a habitat for LLMs. My research has mirrored exactly what you are saying.
I think conceptually, Lisp was an interpreted runtime. However, the combination of chasing efficiency with compilation and perhaps "everything is a file" consuming mindshare, interpreted Lisp seems a largely academic pursuit.
> I think conceptually, Lisp was an interpreted runtime.
This is a strange statement. The manual for Lisp 1.5 describes a compiled language. Lisps have been compiled for over 64 years now using just that version as a baseline. Why do you think Lisp was meant to be interpreted instead?
Hey, I'm probably punching out of my weight class here - I'm basically a Lisp beginner. But I will say that I don't think the manual for Lisp 1.5 gets as much airtime as the original John McCarthy eval statement, which does describe an interpreter. I do think there's a lot of conceptual overlap between an interpreter and a REPL. And while I've not read SICP my understanding is that they teach a Lisp interpreter. And also I think the author of this article is describing an interpreted language.
So I don't think I'm over my skis here. But I appreciate your clarifying point! I've not read the Lisp 1.5 manual but I probably should!
EVAL was described in Lisp, on paper first. Steve Russel realized that the Lisp specification of EVAL can be translated to machine language to produce an interpreter. So he did exactly that, by hand, surprising MacCarthy who had only expected his EVAL to be a reference specification, not source code.
In other words, before there was an interpreter, a manual compilation step already took place with Lisp being translated to code. Several years later, they had code doing that, and it was mentioned in the 1960 paper "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I":
> The LISP programming system is a system for using the IBM 704 computer to compute with symbolic information in the form of S-expressions. It has been or will be used for the following purposes:
> 1. Writing a compiler to compile LISP programs into machine language.
> 2. Writing a program to check proofs in a class of formal logical systems.
> 3. Writing programs for formal differentiation and integration …
> 4. [...]
Conceptually, the specification of EVAL is a kind of term-rewriting system which indicates what is to be calculated from what, without asserting how.
You are ignoring his "conceptually" bit and that is a reference to R.E.P.Loop which is what interpreters do: they read, they evaluate, they output, and loop.
Conceptually is doing a lot of heavy lifting there, then. The evaluation step of many (I won't say most) mainstream (not academic, and not toys people create in class) lisps will do a compilation step. It is not being interpreted any more than gcc interprets your C code. Describing it as interpretation is often wrong, and leads people to the extremely common (even here on HN) mistaken belief that Lisps are strictly interpreted and never compiled.
No reason to leave a mistake (if it was one) or a confusing statement (if it was meant in your, hah, interpretation) unaddressed.
Between 1958 and 1960, it took them a good part of two years to get a compiler going. Little did they know that this costly delay would still have people saying that Lisp is fundamentally interpreted in 2026.
Delaying the publication of key papers in major journals until 1960, and loudly mentioning Lisp compilation as the first application of Lisp, didn't help; too late!
This is just the Wikipedia page for "interpreters" so perhaps this is fake news but
> The first interpreted high-level language was Lisp. Lisp was first implemented by Steve Russell on an IBM 704 computer. Russell had read John McCarthy's paper, "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I", and realized (to McCarthy's surprise) that the Lisp eval function could be implemented in machine code.[3] The result was a working Lisp interpreter which could be used to run Lisp programs, or more properly, "evaluate Lisp expressions".
I.e. his realization that the Lisp eval function would behave as an interpreter came at the same time as his realization that the Lisp specification of the eval function can be translated to machine language. Though he did that by hand, within a short time, they had code doing that.
> Describing it as interpretation is often wrong, and leads people to the extremely common (even here on HN) mistaken belief that Lisps are strictly interpreted and never compiled.
Well, I literally said in my post that basically all Lisp was compiled. And I was replying to a guy saying that I thought all lisp is compiled. So hopefully I'm not contributing to that misconception.
Disagree. Concepually is lifting according to its weight class here. It is entirely irrelevant whether all or most implementations compile. The germinal fact is that a "naive" interpreter implementation of LISP does not in anyway alter the semantics of the language or the code being executed.
> No reason to leave a mistake (if it was one) or a confusing statement (if it was meant in your, hah, interpretation) unaddressed.
Look buddy, I'm not here for snarking others. I am here to learn and exchange ideas.
Note exactly the same but worth mentioning for C/C++ programmers out there: gdb can actually function as some sort of "cheap" live environment for C and C++
When stopped at a breakpoint, you can evaluate C/C++ expressions, modify state, call functions, and, with compile code, have GDB compile and execute new C/C++ code in the context of the running process:
That makes for a surprisingly nice "REPL attached to a running C program" experience. You can poke at the heap, change variables, call into the existing code, and inject little bits of new code without restarting the process.
One use case I have fond memories of was implementing different trees structure and adding a print_dot function that printed the tree in .dot format and whenever I call the function from inside gdb, the xdot window would redraw with an updated tree graph.
I know it isn't really the same thing as a Lisp image where the injected code is become persistent but still nice to have
P.S: If you are trying gdb's tui for the first time and your program is still laden with print statements, you can ungarble the screen after a printf output with Ctrl+L or the refresh command
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 every single time if they want to put their skills on wheels.
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.
Basically all text editors now do syntax highlighting, I have not heard any one say they avoid syntax high-lighting. I personally avoid the usual auto complete interface style and stick with the emacs default of explicitly requesting the editor to completion at point, not because it can't do it or that I am being macho but because I find it distracting and find it obscures code I often want to look at.
I hate with passion GUI's that stop be copying text and other crack that modern IDE's often do.
I don't avoid modern features at all and actively use pretty much all of them. If something like and IDE works for you that's great. But their is not some deep psychological need I am fulfilling, other then using tools that have less friction for me.
Additionally the post is about haskell a very high level language with the type system being the main feature, this persons choice in emacs is clearly different to the type that shun type systems and GC. Additionally I do not actually think the types that shun GC and shun type systems intersect as much as you make out, the types that shun GC are performance obsessed kinds of people in which type systems can improve performance significantly and those that shun type systems are (a dying breed) tend to be those who like scripting languages and hacking something together quickly. Most people recognize that both have their place I think.
Maybe the example of a carpenter who has a set of trusted tools and might like or a chefs set of knives, if we really need to look at other professions and measure are self against them. I think if you ask people why they use text editors (or IDE's) they will give their own valid reasons for each.
Ok I stand corrected, Rob Pike is no fool, I agree the comment seems flippant and a little silly, I guess theirs a few people who shun syntax highlighting.
tonksy also has some interesting opinions on syntax highlighting - not necessarily against highlighting, but taking a more minimalist stance against how highlighting is typically done: https://tonsky.me/blog/syntax-highlighting/
> One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it. Likewise, a splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text. The natural flow of the text is broken, and it takes more brain effort to piece together the individual letters into words and semantics. Cognitively, the reading process becomes slightly less automatic and slightly more conscious; leaving less room in the conscious part of the mind for actually understanding the text.
Right, but... are you reading code in a way in which you need to preserve the “natural flow”? Personally I read a program (made up of discrete chunks of syntax that do things) much differently than a novel, or any piece of natural language in which you’d care about the typography.
I think that's an incredibly ignorant and hostile read, frankly. It's a manifold of human behaviors manifesting as something you're painting with a large brush. In the largest stroke, if you have any empathy and a competent theory of mind, you understand it's simple identity protectionism. People attach their identities to their methodologies and tools, and are generally close-minded. I like to think of it like an energy saving trait hardwired into the human mind, even if it's a little bit annoying.
The behavior also isn't unique to programming at all. You can observe it in the various engineering fields. As a single example, in civil engineering you have the conflict between allowable stress design or load and resistance factor design. You even see the behavior in fields like medicine. Different doctors have different views on different methodologies, treatments, etc.
Ascribing it to the "youth" of programming as a field is strange, not just because of its observability in older professions, but because the things you're complaining about are things that emerged as the field got more mature.
I think there's a serious self-flagellation problem some programmers have for themselves after being talked down to by other fields that you're exemplifying here. There's nothing particularly unique about the social dynamics of programming.
I have literally seen this firsthand enough to consider it repeatable. I am not making up characters for effect. I have seen and worked with people who didn’t want to write tests because they thought it made them appear weak. I have seen people say they use Ruby because they “don’t want a compiler holding their hand” as if a compiler diminished them personally (I have nothing against Ruby specifically).
Programming is a young field compared to basically all the others. It is immature. It is undergoing massive change quickly. It does have an immature, barely developed theory of practice. This has weird effects, just like how other disciplines had weird quirks when they were young too. What was young medicine like?
I have a great deal of empathy and respect for programmers. Same for engineers and doctors. None are infallible. Doesn’t change my read that our (programming) culture could be better than it is in specific ways, which could result in better decision making in the aggregate.
As for your last point, I agree! I’ve worked too closely with them for there to be any mystique left. I don’t want programming to become civil engineering or medicine but I think we can learn things from how they think about quality and systems. They’ve had more practice at it.
I know I've seen enough people online proudly declare their hatred of IDEs and how real men code in text editors often enough to notice it as a pattern.
I don’t like LSPs. They’re slow and bloated. I’ve been using clangd but I think I’ll stop. It’s slow as molasses. It constantly tries to insert headers into source files that cause compilation issues. There are easier and faster ways to jump to definitions.
I don’t use LSPs with Haskell anymore. I work on multiple projects which use different versions of GHC and the base library which means having multiple LSPs installed for each one. Trying to get eMacs to reliably detect which project is using which version is not something I have been able to figure out. Plus it’s slow and uses way too much memory.
At current job I’m doing C# and man does the ecosystem there really push you to use an IDE. Most of my org uses Rider. I find it just as fascinating that people actually like using tools like it. Too bad it doesn’t have a decent text editor built in.
For me, though not blown the dust off it for emacs is to simply use direnv with nix and direnv will set your bins to the correct lsp server configured correctly for that project via nix and then load it using eglot (I have set eglot purposely to not load by default for as you say it can be slow and not always what one wants to load especially for small edits).
I have to agree with your comment about lsp in general they feel a little over engineered or old tags are nicer and feel less bloaty even if less powerful.
You're phrasing this as if using an IDE was always an advantage, but unfortunately this isn't always the case:
-IDEs are more resources hungry, I remember when trying to use CLion on a big C++ codebase, until increasing the garbage collector maximum heap size all I had was a blank screen, after it was just unusably slow...
-even when IDE work, LSP for C++ codebase aren't very good, for example the caller hierarchy is usually very incomplete..
-I remember having been asked quite a few times, about "how do I use the IDE's integrated debugger to debug a target which was available only through ssh and then you had to telnet from one board to another?"
My answer? Use gdb.
That said, I use VSCode now because its multiple tab handling is very nice, but I use it mostly as a glorified text editor (not by choice but because C++ is really IDE's unfriendly).
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.
Yeah and you just have one interface that you have to know and customize rather then 100. not to mention the pleasure of shell mode and and tramp and dired. I feel people are missing out not using emacs or emacs like tools where all your customization and custom functions, bindings and minor modes apply to everything else you do (should they be applicable).
haha I am in fact a long-standing near-vanilla emacs user. never said it being uncurated was a bad thing, the customizability is unrivalled and the reason I use it.
Strongly disagree, Having a generalized interface IE text and being to manipulate things as text using all the same commands and functions is better then bespoke interfaces for everything else. It's not like you don't have custom interfaces for various things but that the interface is a text buffer and can be treated as such in all emacs modes.
I've used IDEs from time to time, but they don't fit how I like to work.
Sometimes I work on my desktop, but most of my work is on a dev server. Some of my work is on my dedicated server at a budget host. I am not interested in an IDE that runs on my desktop and uses magic to edit files on my servers; properly configuring that with an eye towards security is not my idea of a good time. I'm not going to run an IDE on my server at hosting. I don't want to use multiple editors. The only sensible option is to use a terminal based editor for mostly everything. :p
Having used the same editor for programming for ~ 30 years at this point, I'm pretty good at it. When I use an IDE, it always feels more cumbersome ... sometimes it's valuable because I'm doing unfamiliar things anyway and the contextual assistance is sort of nice, but if I know what I'm doing, it gets in my way.
There's more than one way to do things, and if you want to use all the tools, go for it. I'm not trying to convince you not to, I'm just saying why it doesn't work for me.
Because 'engineering' is a different field, with a different software ecosystem? What's fascinating about it? It's pretty blatantly obvious, engineers pay Dassault through the nose for Solidworks because there are no real alternatives. The same is not true for programming.
If there was a high quality CAD server that was interfaced via plugins for programmable 3D editing software like Blender, then we can start making comparisons. Fact of the matter is that this isn't the case, not like what programmers have gotten in the last 20 years. It's absolutely not impossible for such a thing to exist, it just doesn't. Building things like high quality heuristics for the topological naming problem is quite hard.
It doesn't help that almost every IDE in existence these days is also not a real IDE. Visual Studio, Xcode, Jetbrains, etc. are just a more rigid programmable text editor, they lack the "I", and quite a bit of the "E". Compare them with things like LispWorks and Delphi, and the difference is stark. For the former category of "DE"s, there are often tools which are just as high quality, if not higher quality, elsewhere. Speaking as someone that uses a very wide variety of tools, including the ones mentioned, there's really not a lot of point to them unless you just really like their specific UI/UX.
I remember when I moved from netbeans to eclipse and the speed of compilation was amazing. For the uninitiated, Netbeans uses a traditional "compile and run" button, but Eclipse does incremental compilation as you type (and actually wrote its own Java compiler for this purpose, which almost exactly matches the Oracle compiler). You get real errors as you type, and when you press run the program instantly runs.
Didn't Donald Knuth or someone of that era write about this effect in Pascal IDEs?
(The best feature though is that you can run a program containing semantic errors or even minor syntax errors; the body of any function that doesn't compile gets compiled as a throw-exception statement, so you don't have to comment it out when you're working on another part of the code)
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.
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.
> They don’t have to restart the program on exceptions, because the condition system allows resuming the crashing code from anywhere in the stack after the system has been patched with a fix.
I'm "only" using Clojure (which some shall say is not a proper Lisp) and elisp (which is, well, elisp) but I catch every exceptions (including any yet uncaught ones) and I rarely need to restart the app. I've got an helper function to "restart" the app and I can pass a parameter: reset the state of the app or not (usually I don't and keep working with my current app state). As to the main process: I very rarely need to restart the JVM / get a new REPL.
The whole thing is basically a very, very, very long REPL session.
> A consequence of this way of working is that early in a Lisp project, there may not even be any source code to speak of. Instead, the evolving definition of the system exists only in the memory image of the running process and nowhere else.
Yes but be careful... At times this shall bite you: you've got this function or this new definition of that function that you only had working in the REPL and which is not in source code yet. I typically have tests and I run them, from another process, totally unrelated to the one I'm developing in, that I regularly run (not just when I commit): this helps catch at least the most serious "desynch" issues (where the Lisp source code doesn't correspond anymore to what's in the REPL).
> A Lisp programmer does not need to “switch over” to something else because they are already inside their program process. They never “compile and execute” the code because the code is already running and they edit it by hot-swapping code. They never restart in a debugger because they are already inside their program process and can inspect anything they want.
Yup it's all really very sweet. But really: those are all part of that family of languages and not a kludge added later on to the language.
Some people believe that because they have a console in the web dev tools in their browsers that can execute JavaScript code they've got the same thing as a Lisp. It's not anywhere near close to that.
A language server doesn't have to involve live reloading, and normally doesn't? I feel like these are two orthogonal concerns. A language server is used for things like autocomplete and error highlighting.
I don't like them in principle because I believe the language should be more fully integrated with the IDE (like Eclipse does), but they do work, are a step up from syntax highlighting, and are practically a requirement if you have an NxM matrix of languages and IDEs.
I have always viewed the Emacs/Slime/CL development environment as being a more frictionless approach than the compile/link/execute approach of most other languages, but I get the impression there are people who evangelize "image-based coding" without having tried it out themselves.
The idea of not maintaining properly documented sources would terrify me.
As people point out, if you are not careful and execute arbitrary code in the REPL, your source and image can drift out of sync. When I was working on [1], I would go days without relaunching my image, but all the development was done by evaluating code in Emacs buffers and seeing the results right away. Occasionally, things got convoluted enough that I relaunched the process as a sanity check.
For me, the real benefit of iteratively modifying a live image lies in the sense of flow it engenders. I have not felt that sense in languages other than CL. I sometimes explain the feeling by saying than CL is the only language that I don't feel is fighting me.
I asked a similar question above, but can you talk more about the ergonomics of keeping the source and the image in sync? Is this generally a manual process in CL?
> There’s no way to write Haskell that puts us inside the program process, so we will still need to restart in a debugger.
If you’re regularly using a debugger while developing ordinary Haskell programs, you’re doing something terribly wrong. Possibly writing in a very imperative style?
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.
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.
I don't object to any of this. "Restart this system from initial state" is quite a bit more common than people imagine in CL. I was hinting at it perhaps being even more common than image-based development, though don't quote me on that. I personally don't even really create Lisp images in dev (save for creating executables that I don't then further modify, which are technically images in SBCL).
Incremental runtime modification is great for development, but I very frequently restart (from sources) every so often, and certainly at least before deployment to verify everything is working as expected. Sometimes because it's completely necessary, sometimes for my own sanity.
For production, I think it's a very "neat" thing to be able to do and I've heard some great stories (no personal experience), but it's definitely a foot gun if not used very carefully.
Can you explain how you sync back to code, in practice?
In other words - if you modify the run time, are you then able to mirror those changes in your codebase and then reboot?
tl;dr you just don't really do that.
99% of the time, you simply write the code or change in the sources first, then compile/run it in the runtime.
If you're modifying the runtime directly at the REPL without having sources, good luck? or you don't really care about persisting those changes. CL has pretty good introspection, so you could look at the source expression of a function defined at the REPL for example, if you really wanted to recover something (and happened to put the change in a function first), but this isn't always reliable.
I also found the description of Lisp development weird, as if it's a second-hand repetition of someone else describing watching a Lisp developer in action.
The workflow I always use is to write code in my editor and use a keyboard shortcut to evaluate it. Typing directly into the REPL is for one-off state updates, inspection, experiments, and similar throwaway code.
Even the original MIT Lisp Machine was designed around editing source files, there were "compile the current function" keybindings and menu options in the version of Emacs for it.
You could also type an individual function into the repl then pretty-print it to a file but that typically expands out any read macros that you may have used.
Awesome. Got any more info? Were any of the Lisp Machines image based?
Interlisp-D was more image based.
You could type something in to the repl then add it to a file later.
There was a structure editor that worked on the s-expression of a function, including any comments as they were represented as a special form within that structure.
See section 7 of the introductory guide [1].[1] https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/xe...
That intro would make much more sense if you replaced "Lisp" with "Smalltalk".
I am not a Lisp developer by trade, but I accidentally made an interpreted Lisp as a habitat for LLMs. My research has mirrored exactly what you are saying.
I think conceptually, Lisp was an interpreted runtime. However, the combination of chasing efficiency with compilation and perhaps "everything is a file" consuming mindshare, interpreted Lisp seems a largely academic pursuit.
It's really great for running agents, though.
> I think conceptually, Lisp was an interpreted runtime.
This is a strange statement. The manual for Lisp 1.5 describes a compiled language. Lisps have been compiled for over 64 years now using just that version as a baseline. Why do you think Lisp was meant to be interpreted instead?
Hey, I'm probably punching out of my weight class here - I'm basically a Lisp beginner. But I will say that I don't think the manual for Lisp 1.5 gets as much airtime as the original John McCarthy eval statement, which does describe an interpreter. I do think there's a lot of conceptual overlap between an interpreter and a REPL. And while I've not read SICP my understanding is that they teach a Lisp interpreter. And also I think the author of this article is describing an interpreted language.
So I don't think I'm over my skis here. But I appreciate your clarifying point! I've not read the Lisp 1.5 manual but I probably should!
EVAL was described in Lisp, on paper first. Steve Russel realized that the Lisp specification of EVAL can be translated to machine language to produce an interpreter. So he did exactly that, by hand, surprising MacCarthy who had only expected his EVAL to be a reference specification, not source code.
In other words, before there was an interpreter, a manual compilation step already took place with Lisp being translated to code. Several years later, they had code doing that, and it was mentioned in the 1960 paper "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I":
> The LISP programming system is a system for using the IBM 704 computer to compute with symbolic information in the form of S-expressions. It has been or will be used for the following purposes:
> 1. Writing a compiler to compile LISP programs into machine language.
> 2. Writing a program to check proofs in a class of formal logical systems.
> 3. Writing programs for formal differentiation and integration …
> 4. [...]
Conceptually, the specification of EVAL is a kind of term-rewriting system which indicates what is to be calculated from what, without asserting how.
> Steve Russel realized that the Lisp specification of EVAL can be translated to machine language to produce an interpreter.
So just to be clear, you are here confirming that the first implementation of Lisp was in fact an interpreter?
The first implementation of Lisp was Steve Russel, hand-translating Lisp written on paper to machine code.
You are ignoring his "conceptually" bit and that is a reference to R.E.P.Loop which is what interpreters do: they read, they evaluate, they output, and loop.
Conceptually is doing a lot of heavy lifting there, then. The evaluation step of many (I won't say most) mainstream (not academic, and not toys people create in class) lisps will do a compilation step. It is not being interpreted any more than gcc interprets your C code. Describing it as interpretation is often wrong, and leads people to the extremely common (even here on HN) mistaken belief that Lisps are strictly interpreted and never compiled.
No reason to leave a mistake (if it was one) or a confusing statement (if it was meant in your, hah, interpretation) unaddressed.
Between 1958 and 1960, it took them a good part of two years to get a compiler going. Little did they know that this costly delay would still have people saying that Lisp is fundamentally interpreted in 2026.
Delaying the publication of key papers in major journals until 1960, and loudly mentioning Lisp compilation as the first application of Lisp, didn't help; too late!
This is just the Wikipedia page for "interpreters" so perhaps this is fake news but
> The first interpreted high-level language was Lisp. Lisp was first implemented by Steve Russell on an IBM 704 computer. Russell had read John McCarthy's paper, "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I", and realized (to McCarthy's surprise) that the Lisp eval function could be implemented in machine code.[3] The result was a working Lisp interpreter which could be used to run Lisp programs, or more properly, "evaluate Lisp expressions".
I.e. his realization that the Lisp eval function would behave as an interpreter came at the same time as his realization that the Lisp specification of the eval function can be translated to machine language. Though he did that by hand, within a short time, they had code doing that.
> Describing it as interpretation is often wrong, and leads people to the extremely common (even here on HN) mistaken belief that Lisps are strictly interpreted and never compiled.
Well, I literally said in my post that basically all Lisp was compiled. And I was replying to a guy saying that I thought all lisp is compiled. So hopefully I'm not contributing to that misconception.
Disagree. Concepually is lifting according to its weight class here. It is entirely irrelevant whether all or most implementations compile. The germinal fact is that a "naive" interpreter implementation of LISP does not in anyway alter the semantics of the language or the code being executed.
> No reason to leave a mistake (if it was one) or a confusing statement (if it was meant in your, hah, interpretation) unaddressed.
Look buddy, I'm not here for snarking others. I am here to learn and exchange ideas.
Note exactly the same but worth mentioning for C/C++ programmers out there: gdb can actually function as some sort of "cheap" live environment for C and C++
When stopped at a breakpoint, you can evaluate C/C++ expressions, modify state, call functions, and, with compile code, have GDB compile and execute new C/C++ code in the context of the running process:
That makes for a surprisingly nice "REPL attached to a running C program" experience. You can poke at the heap, change variables, call into the existing code, and inject little bits of new code without restarting the process.One use case I have fond memories of was implementing different trees structure and adding a print_dot function that printed the tree in .dot format and whenever I call the function from inside gdb, the xdot window would redraw with an updated tree graph.
I know it isn't really the same thing as a Lisp image where the injected code is become persistent but still nice to have
P.S: If you are trying gdb's tui for the first time and your program is still laden with print statements, you can ungarble the screen after a printf output with Ctrl+L or the refresh command
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 every single time if they want to put their skills on wheels.
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.
Basically all text editors now do syntax highlighting, I have not heard any one say they avoid syntax high-lighting. I personally avoid the usual auto complete interface style and stick with the emacs default of explicitly requesting the editor to completion at point, not because it can't do it or that I am being macho but because I find it distracting and find it obscures code I often want to look at.
I hate with passion GUI's that stop be copying text and other crack that modern IDE's often do.
I don't avoid modern features at all and actively use pretty much all of them. If something like and IDE works for you that's great. But their is not some deep psychological need I am fulfilling, other then using tools that have less friction for me.
Additionally the post is about haskell a very high level language with the type system being the main feature, this persons choice in emacs is clearly different to the type that shun type systems and GC. Additionally I do not actually think the types that shun GC and shun type systems intersect as much as you make out, the types that shun GC are performance obsessed kinds of people in which type systems can improve performance significantly and those that shun type systems are (a dying breed) tend to be those who like scripting languages and hacking something together quickly. Most people recognize that both have their place I think.
Maybe the example of a carpenter who has a set of trusted tools and might like or a chefs set of knives, if we really need to look at other professions and measure are self against them. I think if you ask people why they use text editors (or IDE's) they will give their own valid reasons for each.
> I have not heard any one say they avoid syntax high-lighting.
Here's one of the Go creators "explaining" why the Go website lacks highlighting.
https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...
https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/E2mQ...
Ok I stand corrected, Rob Pike is no fool, I agree the comment seems flippant and a little silly, I guess theirs a few people who shun syntax highlighting.
tonksy also has some interesting opinions on syntax highlighting - not necessarily against highlighting, but taking a more minimalist stance against how highlighting is typically done: https://tonsky.me/blog/syntax-highlighting/
> One of the basic rules of thumb in typography is that, when writing a piece of text, you should choose one typeface and stick to it. Likewise, a splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text. The natural flow of the text is broken, and it takes more brain effort to piece together the individual letters into words and semantics. Cognitively, the reading process becomes slightly less automatic and slightly more conscious; leaving less room in the conscious part of the mind for actually understanding the text.
https://www.linusakesson.net/programming/syntaxhighlighting/
Right, but... are you reading code in a way in which you need to preserve the “natural flow”? Personally I read a program (made up of discrete chunks of syntax that do things) much differently than a novel, or any piece of natural language in which you’d care about the typography.
That's just a rant trying to disguise itself as objective.
He is very wrong. color coded syntax makes code MUCH easier to read.
I think that's an incredibly ignorant and hostile read, frankly. It's a manifold of human behaviors manifesting as something you're painting with a large brush. In the largest stroke, if you have any empathy and a competent theory of mind, you understand it's simple identity protectionism. People attach their identities to their methodologies and tools, and are generally close-minded. I like to think of it like an energy saving trait hardwired into the human mind, even if it's a little bit annoying.
The behavior also isn't unique to programming at all. You can observe it in the various engineering fields. As a single example, in civil engineering you have the conflict between allowable stress design or load and resistance factor design. You even see the behavior in fields like medicine. Different doctors have different views on different methodologies, treatments, etc.
Ascribing it to the "youth" of programming as a field is strange, not just because of its observability in older professions, but because the things you're complaining about are things that emerged as the field got more mature.
I think there's a serious self-flagellation problem some programmers have for themselves after being talked down to by other fields that you're exemplifying here. There's nothing particularly unique about the social dynamics of programming.
I have literally seen this firsthand enough to consider it repeatable. I am not making up characters for effect. I have seen and worked with people who didn’t want to write tests because they thought it made them appear weak. I have seen people say they use Ruby because they “don’t want a compiler holding their hand” as if a compiler diminished them personally (I have nothing against Ruby specifically).
Programming is a young field compared to basically all the others. It is immature. It is undergoing massive change quickly. It does have an immature, barely developed theory of practice. This has weird effects, just like how other disciplines had weird quirks when they were young too. What was young medicine like?
I have a great deal of empathy and respect for programmers. Same for engineers and doctors. None are infallible. Doesn’t change my read that our (programming) culture could be better than it is in specific ways, which could result in better decision making in the aggregate.
As for your last point, I agree! I’ve worked too closely with them for there to be any mystique left. I don’t want programming to become civil engineering or medicine but I think we can learn things from how they think about quality and systems. They’ve had more practice at it.
I know I've seen enough people online proudly declare their hatred of IDEs and how real men code in text editors often enough to notice it as a pattern.
"Real Programmers Don't Use Pascal" https://homepages.inf.ed.ac.uk/rni/papers/realprg.html
Well, put forward your tool-chain and we'll start insulting immediately
I just generally use the JetBrains IDE for whatever language I'm using.
I don’t like LSPs. They’re slow and bloated. I’ve been using clangd but I think I’ll stop. It’s slow as molasses. It constantly tries to insert headers into source files that cause compilation issues. There are easier and faster ways to jump to definitions.
I don’t use LSPs with Haskell anymore. I work on multiple projects which use different versions of GHC and the base library which means having multiple LSPs installed for each one. Trying to get eMacs to reliably detect which project is using which version is not something I have been able to figure out. Plus it’s slow and uses way too much memory.
At current job I’m doing C# and man does the ecosystem there really push you to use an IDE. Most of my org uses Rider. I find it just as fascinating that people actually like using tools like it. Too bad it doesn’t have a decent text editor built in.
For me, though not blown the dust off it for emacs is to simply use direnv with nix and direnv will set your bins to the correct lsp server configured correctly for that project via nix and then load it using eglot (I have set eglot purposely to not load by default for as you say it can be slow and not always what one wants to load especially for small edits).
I have to agree with your comment about lsp in general they feel a little over engineered or old tags are nicer and feel less bloaty even if less powerful.
Man, I was about to try setting one up with Emacs since an issue I had has finally been fixed, and now I am questioning if it's even worth the effort.
Not sure if you are on Emacs 31 yet, but another HNer told me the version issue was fixed for them, but I haven't tried.
> I’m doing C# and man does the ecosystem there really push you to use an IDE.
I had to stop using Emacs for C# dev for a similar reason. Well that, and being on Windows for work only further compounded the issue.
Which is very strange when you remember that Visual C++ 6 on Windows 95 on whatever hardware from that era was pretty fast.
You're phrasing this as if using an IDE was always an advantage, but unfortunately this isn't always the case:
-IDEs are more resources hungry, I remember when trying to use CLion on a big C++ codebase, until increasing the garbage collector maximum heap size all I had was a blank screen, after it was just unusably slow...
-even when IDE work, LSP for C++ codebase aren't very good, for example the caller hierarchy is usually very incomplete..
-I remember having been asked quite a few times, about "how do I use the IDE's integrated debugger to debug a target which was available only through ssh and then you had to telnet from one board to another?" My answer? Use gdb.
That said, I use VSCode now because its multiple tab handling is very nice, but I use it mostly as a glorified text editor (not by choice but because C++ is really IDE's unfriendly).
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.
a typographical river
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.
They are using Emacs that's basically an IDE.
IDE tends to be a curated tool for one specific language though. I guess in that sense Emacs is an ELisp IDE, but without any sense of curation.
Yeah and you just have one interface that you have to know and customize rather then 100. not to mention the pleasure of shell mode and and tramp and dired. I feel people are missing out not using emacs or emacs like tools where all your customization and custom functions, bindings and minor modes apply to everything else you do (should they be applicable).
haha I am in fact a long-standing near-vanilla emacs user. never said it being uncurated was a bad thing, the customizability is unrivalled and the reason I use it.
Yes just adding to the point you gave.
An interface that does everything does nothing well.
Strongly disagree, Having a generalized interface IE text and being to manipulate things as text using all the same commands and functions is better then bespoke interfaces for everything else. It's not like you don't have custom interfaces for various things but that the interface is a text buffer and can be treated as such in all emacs modes.
What's Eclipse then?
...a series of IDEs offering curated experiences for a specific target language
The Java and C++ IDEs are separate packages built on a shared base.
What is it if you install the Java and C++ plugins together?
Bloated.
I've used IDEs from time to time, but they don't fit how I like to work.
Sometimes I work on my desktop, but most of my work is on a dev server. Some of my work is on my dedicated server at a budget host. I am not interested in an IDE that runs on my desktop and uses magic to edit files on my servers; properly configuring that with an eye towards security is not my idea of a good time. I'm not going to run an IDE on my server at hosting. I don't want to use multiple editors. The only sensible option is to use a terminal based editor for mostly everything. :p
Having used the same editor for programming for ~ 30 years at this point, I'm pretty good at it. When I use an IDE, it always feels more cumbersome ... sometimes it's valuable because I'm doing unfamiliar things anyway and the contextual assistance is sort of nice, but if I know what I'm doing, it gets in my way.
There's more than one way to do things, and if you want to use all the tools, go for it. I'm not trying to convince you not to, I'm just saying why it doesn't work for me.
Because 'engineering' is a different field, with a different software ecosystem? What's fascinating about it? It's pretty blatantly obvious, engineers pay Dassault through the nose for Solidworks because there are no real alternatives. The same is not true for programming.
If there was a high quality CAD server that was interfaced via plugins for programmable 3D editing software like Blender, then we can start making comparisons. Fact of the matter is that this isn't the case, not like what programmers have gotten in the last 20 years. It's absolutely not impossible for such a thing to exist, it just doesn't. Building things like high quality heuristics for the topological naming problem is quite hard.
It doesn't help that almost every IDE in existence these days is also not a real IDE. Visual Studio, Xcode, Jetbrains, etc. are just a more rigid programmable text editor, they lack the "I", and quite a bit of the "E". Compare them with things like LispWorks and Delphi, and the difference is stark. For the former category of "DE"s, there are often tools which are just as high quality, if not higher quality, elsewhere. Speaking as someone that uses a very wide variety of tools, including the ones mentioned, there's really not a lot of point to them unless you just really like their specific UI/UX.
I remember when I moved from netbeans to eclipse and the speed of compilation was amazing. For the uninitiated, Netbeans uses a traditional "compile and run" button, but Eclipse does incremental compilation as you type (and actually wrote its own Java compiler for this purpose, which almost exactly matches the Oracle compiler). You get real errors as you type, and when you press run the program instantly runs.
Didn't Donald Knuth or someone of that era write about this effect in Pascal IDEs?
(The best feature though is that you can run a program containing semantic errors or even minor syntax errors; the body of any function that doesn't compile gets compiled as a throw-exception statement, so you don't have to comment it out when you're working on another part of the code)
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.
my favorite part of Haskell is that it's thorny which keeps bads away. like a good washout course in college. keeps the community "pure" kek
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.
> They don’t have to restart the program on exceptions, because the condition system allows resuming the crashing code from anywhere in the stack after the system has been patched with a fix.
I'm "only" using Clojure (which some shall say is not a proper Lisp) and elisp (which is, well, elisp) but I catch every exceptions (including any yet uncaught ones) and I rarely need to restart the app. I've got an helper function to "restart" the app and I can pass a parameter: reset the state of the app or not (usually I don't and keep working with my current app state). As to the main process: I very rarely need to restart the JVM / get a new REPL.
The whole thing is basically a very, very, very long REPL session.
> A consequence of this way of working is that early in a Lisp project, there may not even be any source code to speak of. Instead, the evolving definition of the system exists only in the memory image of the running process and nowhere else.
Yes but be careful... At times this shall bite you: you've got this function or this new definition of that function that you only had working in the REPL and which is not in source code yet. I typically have tests and I run them, from another process, totally unrelated to the one I'm developing in, that I regularly run (not just when I commit): this helps catch at least the most serious "desynch" issues (where the Lisp source code doesn't correspond anymore to what's in the REPL).
> A Lisp programmer does not need to “switch over” to something else because they are already inside their program process. They never “compile and execute” the code because the code is already running and they edit it by hot-swapping code. They never restart in a debugger because they are already inside their program process and can inspect anything they want.
Yup it's all really very sweet. But really: those are all part of that family of languages and not a kludge added later on to the language.
Some people believe that because they have a console in the web dev tools in their browsers that can execute JavaScript code they've got the same thing as a Lisp. It's not anywhere near close to that.
A language server doesn't have to involve live reloading, and normally doesn't? I feel like these are two orthogonal concerns. A language server is used for things like autocomplete and error highlighting.
I don't like them in principle because I believe the language should be more fully integrated with the IDE (like Eclipse does), but they do work, are a step up from syntax highlighting, and are practically a requirement if you have an NxM matrix of languages and IDEs.
[flagged]
I have always viewed the Emacs/Slime/CL development environment as being a more frictionless approach than the compile/link/execute approach of most other languages, but I get the impression there are people who evangelize "image-based coding" without having tried it out themselves.
The idea of not maintaining properly documented sources would terrify me.
As people point out, if you are not careful and execute arbitrary code in the REPL, your source and image can drift out of sync. When I was working on [1], I would go days without relaunching my image, but all the development was done by evaluating code in Emacs buffers and seeing the results right away. Occasionally, things got convoluted enough that I relaunched the process as a sanity check.
For me, the real benefit of iteratively modifying a live image lies in the sense of flow it engenders. I have not felt that sense in languages other than CL. I sometimes explain the feeling by saying than CL is the only language that I don't feel is fighting me.
[1] https://github.com/kaveh808/kons-9
I asked a similar question above, but can you talk more about the ergonomics of keeping the source and the image in sync? Is this generally a manual process in CL?
> There’s no way to write Haskell that puts us inside the program process, so we will still need to restart in a debugger.
If you’re regularly using a debugger while developing ordinary Haskell programs, you’re doing something terribly wrong. Possibly writing in a very imperative style?
It is always cool to implement a powershell code in Linux style. Credits to the author of GHCup
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 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've been playing around with a fully interpreted Lisp as a habitat for LLMs to code in, and honestly it's really great
[dead]