6 ms·

There are some truly powerful and unique things about Lisps, but I wish articles like this would stop including REPLs and hot-reloading. The former have been ta

There are some truly powerful and unique things about Lisps, but I wish articles like this would stop including REPLs and hot-reloading. The former have been table stakes for interpreted languages (and some compiled ones!) for years, and the latter is neither unique nor particularly widely used (hot reloads have to tangle with state and patching, so resetting the world for ease of reasoning is considered a best practice for a reason).

taeric 3mo ago
Largely agreed. I do think it is worth highlighting how many advanced parts of hot-reloading have already been covered in Common Lisp. Same with highlighting how the REPL is largely not used to directly type into, but is instead a very powerful interface for tools to interact with a running image. But, again agreed that simply these existing are not that notable today.
spinningarrow 3mo ago
> The former have been table stakes for interpreted languages I used to think so too back in the day when I was getting into Clojure. It was much later when I realized that when Lisp people talk about the REPL they’re usually talking not so much about the interactive CLI where you can evaluate commands easily but more so the ability to connect your program to a live session where you can quickly evaluate forms within your text editor and in the context of your running application, which enables much more interactive development than in other interpreted languages.
- dismalaf 3mo ago
  You've been able to do this in Ruby since I can remember. Not a lot of editors take advantage of it though...
  - iLemming 3mo ago
    No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holistic, overall experience working with it. Like, I don't understand, do people think that tons of Clojurians or Common Lispers who fall in love with the language after decades of working and getting seasoned in literally dozens of different PLs are on some kind of delusional trip or something? Guys, just take a gander at Clojurians Slack; see what people are working on, what kind of stuff they're building; check their profiles. Many of them are the battle-scarred veterans of coding. Sure, some of them may have wrong opinions, but surely they can't be all wrong, can't they?
    - dismalaf 3mo ago
      Tell me your knowledge of Ruby is surface level without telling me... I used Clojure when it first came out, I've used Common Lisp for years, I've also used languages like Smalltalk and many others. Yes, Lisp environments are nice, but sometimes I think Lispers are so insular they don't realize that other languages have similar things. R, Julia and Ruby have similar environments. Smalltalk is next level. And homoiconicity is great for macros and parsing but it's late-binding that enables the live programming behaviour, which isn't exclusive to Lisp. Also if you'd ever gotten deep into say, SB-ALIEN, you'd know the limitations too; Common Lisp isn't magic, it can't just redefine say, instantiated structs in memory. It relies on pointers then switching references on the fly.
      - iLemming 3mo ago
        > they don't realize that other languages have similar things Yes they do. God, how did you (and apparently you're not alone) read my rant and still got it 100% backwards? I specifically hinted about not picking a single aspect of a language - REPL or whatever. What is so confusing about my wording on "holistic, overall experience working with it"?
        dismalaf 3mo ago
        Apart from your rant, this is the most pertinent part of what you said: > There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages And it's false. There's nothing special about a REPL in a homoiconic language. Homoiconicity has nothing to do with a REPL or tools. I do however think SBCL has a very nice environment with great tools (especially it's compiler) and that's why I've used it a lot over the years, but I really think you underestimate the environments in other languages (including the "holistic, overall experience").
        iLemming 3mo ago
        > And it's false. There's nothing special about a REPL You are wrong. You might be correct about the workflow but still wrong about the semantics. Pedantically, your notion is false, because homoiconism gives the REPL a genuine capability (program-as-manipulable-data across the read/eval boundary) that non-homoiconic REPLs lack.
- lurkercodemnky 3mo ago
  you can do that in a python debugger?
  - vindarel 3mo ago
    the python debugger is cool but is an inferior experience. It isn't only about a REPL, but about the editing experience, and about the language being thought from the ground up for long-living programs. See: https://mikelevins.github.io/posts/2020-12-18-repl-driven/ https://mikelevins.github.io/posts/2020-12-18-repl-driven/
  - iLemming 3mo ago
    [dead]
jolt42 3mo ago
But with Clojure and immutable by default, hot reload is a real thing, it sounds like not just on JVM but even among lisps.
- veqq 3mo ago
  Clojure barely let you import packages without restarting the JVM recently in its life.
  - iLemming 3mo ago
    But it has this capability and had it for a while. What's your complain?
  - gf000 3mo ago
    Can you expand on that? I am mildly experienced with Clojure, and much more so with the JVM and I see no reason for that to happen (besides perhaps some kind of module shenanigans or importing stuff that requires special flags?)
- KingMob 3mo ago
  Ehh, no. In fact, other Lisps are actually slightly better at hot reloading because they're not hampered by the JVM's limits. Check out stuff like CHANGE-CLASS or whole image loading.
kazinator 3mo ago
Not all Lisp dialects have well-developed hot patching systems. The OOP system has to be carefully designed for it. What if a class definition is superseded by a reload, but there are existing instances? The Common Lisp dialect of Lisp has useful answers to questions like this, but not necessarily every Lisp you come across. Even Bash supports hot-reloading. I've developed modules that are updated in place by sourcing: $ . /path/to/script.sh
munificent 3mo ago
> and the latter is neither unique nor particularly widely used (hot reloads have to tangle with state and patching, so resetting the world for ease of reasoning is considered a best practice for a reason). For what it's worth, hot reload is very widely used in Dart/Flutter. When you are writing UI code using a reactive style framework where rendering the UI appears to be "generate a new UI from scratch on each frame", it's more straightforward to have an intuition about what does and doesn't get reloaded. It's not perfect, of course. But it works really well for the kind of changes you make when iterating on a user experience.
ux266478 3mo ago
Generally speaking, the pain of handling hot patching depends highly on the structure of your codebase and the reason for hot patching to begin with. For a structure-of-arrays architecture, or for fixing logic errors at run-time, it's really no big deal at all. It is limited utility, but if you start out from the mindset it's something you'll use a lot, those limitations start disappearing rather quickly.

taeric 3mo ago

Largely agreed. I do think it is worth highlighting how many advanced parts of hot-reloading have already been covered in Common Lisp. Same with highlighting how the REPL is largely not used to directly type into, but is instead a very powerful interface for tools to interact with a running image. But, again agreed that simply these existing are not that notable today.

spinningarrow 3mo ago

> The former have been table stakes for interpreted languages I used to think so too back in the day when I was getting into Clojure. It was much later when I realized that when Lisp people talk about the REPL they’re usually talking not so much about the interactive CLI where you can evaluate commands easily but more so the ability to connect your program to a live session where you can quickly evaluate forms within your text editor and in the context of your running application, which enables much more interactive development than in other interpreted languages.

dismalaf 3mo ago
You've been able to do this in Ruby since I can remember. Not a lot of editors take advantage of it though...
- iLemming 3mo ago
  No. There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages - Ruby, Python, Haskell, etc. Every single stage there in Read-Eval-Print-Loop differs. Man, it gets so exhausting trying to convince every PL critic who grabs a single (or a couple) of axis of any language and tries to dispute the value of a language without ever understanding the holistic, overall experience working with it. Like, I don't understand, do people think that tons of Clojurians or Common Lispers who fall in love with the language after decades of working and getting seasoned in literally dozens of different PLs are on some kind of delusional trip or something? Guys, just take a gander at Clojurians Slack; see what people are working on, what kind of stuff they're building; check their profiles. Many of them are the battle-scarred veterans of coding. Sure, some of them may have wrong opinions, but surely they can't be all wrong, can't they?
  - dismalaf 3mo ago
    Tell me your knowledge of Ruby is surface level without telling me... I used Clojure when it first came out, I've used Common Lisp for years, I've also used languages like Smalltalk and many others. Yes, Lisp environments are nice, but sometimes I think Lispers are so insular they don't realize that other languages have similar things. R, Julia and Ruby have similar environments. Smalltalk is next level. And homoiconicity is great for macros and parsing but it's late-binding that enables the live programming behaviour, which isn't exclusive to Lisp. Also if you'd ever gotten deep into say, SB-ALIEN, you'd know the limitations too; Common Lisp isn't magic, it can't just redefine say, instantiated structs in memory. It relies on pointers then switching references on the fly.
    - iLemming 3mo ago
      > they don't realize that other languages have similar things Yes they do. God, how did you (and apparently you're not alone) read my rant and still got it 100% backwards? I specifically hinted about not picking a single aspect of a language - REPL or whatever. What is so confusing about my wording on "holistic, overall experience working with it"?
      - dismalaf 3mo ago
        Apart from your rant, this is the most pertinent part of what you said: > There is real, palpable, practical, functional difference between working a Lisp REPL and a REPL in a non-homoiconic languages And it's false. There's nothing special about a REPL in a homoiconic language. Homoiconicity has nothing to do with a REPL or tools. I do however think SBCL has a very nice environment with great tools (especially it's compiler) and that's why I've used it a lot over the years, but I really think you underestimate the environments in other languages (including the "holistic, overall experience").
        iLemming 3mo ago
        > And it's false. There's nothing special about a REPL You are wrong. You might be correct about the workflow but still wrong about the semantics. Pedantically, your notion is false, because homoiconism gives the REPL a genuine capability (program-as-manipulable-data across the read/eval boundary) that non-homoiconic REPLs lack.
lurkercodemnky 3mo ago
you can do that in a python debugger?
- vindarel 3mo ago
  the python debugger is cool but is an inferior experience. It isn't only about a REPL, but about the editing experience, and about the language being thought from the ground up for long-living programs. See: https://mikelevins.github.io/posts/2020-12-18-repl-driven/ https://mikelevins.github.io/posts/2020-12-18-repl-driven/
- iLemming 3mo ago
  [dead]

jolt42 3mo ago

But with Clojure and immutable by default, hot reload is a real thing, it sounds like not just on JVM but even among lisps.

veqq 3mo ago
Clojure barely let you import packages without restarting the JVM recently in its life.
- iLemming 3mo ago
  But it has this capability and had it for a while. What's your complain?
- gf000 3mo ago
  Can you expand on that? I am mildly experienced with Clojure, and much more so with the JVM and I see no reason for that to happen (besides perhaps some kind of module shenanigans or importing stuff that requires special flags?)
KingMob 3mo ago
Ehh, no. In fact, other Lisps are actually slightly better at hot reloading because they're not hampered by the JVM's limits. Check out stuff like CHANGE-CLASS or whole image loading.

kazinator 3mo ago

Not all Lisp dialects have well-developed hot patching systems. The OOP system has to be carefully designed for it. What if a class definition is superseded by a reload, but there are existing instances? The Common Lisp dialect of Lisp has useful answers to questions like this, but not necessarily every Lisp you come across. Even Bash supports hot-reloading. I've developed modules that are updated in place by sourcing: $ . /path/to/script.sh

munificent 3mo ago

> and the latter is neither unique nor particularly widely used (hot reloads have to tangle with state and patching, so resetting the world for ease of reasoning is considered a best practice for a reason). For what it's worth, hot reload is very widely used in Dart/Flutter. When you are writing UI code using a reactive style framework where rendering the UI appears to be "generate a new UI from scratch on each frame", it's more straightforward to have an intuition about what does and doesn't get reloaded. It's not perfect, of course. But it works really well for the kind of changes you make when iterating on a user experience.

ux266478 3mo ago

Generally speaking, the pain of handling hot patching depends highly on the structure of your codebase and the reason for hot patching to begin with. For a structure-of-arrays architecture, or for fixing logic errors at run-time, it's really no big deal at all. It is limited utility, but if you start out from the mindset it's something you'll use a lot, those limitations start disappearing rather quickly.