Ah, in an alternate world where Brendan Eich wasn't pressured by his superiors to make JS more Java-like, we could have had something like this as very normal.
I wonder how much faster that would have pushed the world into FP ideas. While sometimes I prefer the bracket/C syntax, I wonder how things would have evolved if JS was a lisp originally. Instead of things moving to TypeScript, would they be moving to something like typed Lisp or OCaml, or PureScript ?
I wonder if, in that world, Lisp would be the boring corporate language, and HN would dream of a world where object orientation (which is clearly superior) never had a chance to leap from academia to the mainstream, and hackers post their niche flavors of Java and Smalltalk here.
Is CL really particularly more “functional” than JavaScript? I don’t know CL but I know it bears some passing similarity to Emacs Lisp, which is usually written in a pretty imperative style. Sure, it has first-class closures but so does JS.
I kind of agree, but in the interest of discussion: even if CL isn't necessarily a more functional language in practice, culturally it's got a long history of being more functional. It took something like a decade at least for people to widely recognize to how elegant (in its quirky way) JavaScript could be. Just as a point of comparison (I'm sure the idea goes further back) PAIP - one of the definitive CL books - was first published in 1991 and encourages pure functions and immutability wherever possible.
Devs in the 90s were handed a language that looked like a weird Java and so they programmed it like a weird Java. If they were handed a language that looked like Lisp instead, maybe they would have made their way to SICP that much sooner.
CL is the Ditto (pokemon) of programming langauges. It commits to nothing and does everything better than you'd expect. The problem is its very much a lone warrior type of language. you can attain great productivity due to macros and just how maleable it is but it makes it near impossible to get a team to work together on it without very extensive styling and conventions strictly adhered to by the team. In a way, you could say its a direct influence to go, in that the go team saw everything common lisp did and decided to do the opposite.
> It commits to nothing and does everything better than you'd expect.
Idk man, every time someone makes that claim my immediate reaction is: "what's the catch?". I much rather use 5 tools designed for specific purposes than general-purpose tools that are 50% good at 5 tasks.
the catch is that the langauge is so maleable that no two lisp codebases look the same. Makes it very difficult to establish broader idioms. But in terms of what it cando, its got ridiculously good runtime speed for how dymanic it is and the debugger is one of the best around. you can literally pause on an exception, rewind, fix your code and continue from where you left off.
I love the restarts system but the fact that the industry as a whole chose other approaches makes me wonder if there's something the "wisdom of the crowds" knows that I'm not aware of.
> you can literally pause on an exception, rewind, fix your code and continue from where you left off.
Does it only work on source codes or can I distribute a binary and let my users debug the code like this? Should I distribute the 'image' for it to work?
And is the fix temporary (until the program dies) or permanant?
> I love the restarts system but the fact that the industry as a whole chose other approaches makes me wonder if there's something the "wisdom of the crowds" knows that I'm not aware of.
The restart system is complex, harder to implement, and harder to reason about (it has more "spooky action at a distance", much of it determined at runtime and not compile time).
The "wisdom of the crowds" will generally favor systems that are either:
1. Easier to implement (including sustainment work in the future)
2. Easier to use (or reason about in this case)
Sometimes you get things that are both, but it's often not possible (or feasible) to find or make systems that are both easy to use and easy to implement.
Checked exceptions and explicit error returns are one of those things that happen to provide both (1) and (2) (sort of on 2: often more upfront work, but better reasonability). They're easier to implement for language developers (everything is known at compile time, there is less needed in terms of runtime support especially for explicit error returns), and they're easier to create static tooling for which helps users (programmers). Even without tooling, the explicitness and locality of information makes them more reasonable.
Unchecked exceptions are harder to implement (for instance, the need for handling cleanup as you unwind the stack, which could happen at any point in a function's execution), and they are harder to build static tooling for and harder for programmers to reason about. Common Lisp's conditions and restarts are even harder on all fronts.
This isn't a bad thing, it's a powerful tool. But it means that it won't be mainstream once easier alternatives come along. All the wisdom of the crowds has told us on this is that checked exceptions and explicit error returns are easier. Not that one is better or worse than the other.
> makes me wonder if there's something the "wisdom of the crowds" knows that I'm not aware of.
As I alluded to earlier, its really hard to scale a dev team when the language does nothing to keep you on the rails. As an engineer, I hate go for its lack of abstractions and verbosity. As a CTO, I can appreciate that its trying to reduce the friction in making sure all code looks familiar and that any engineer can be rotated into it. TLDR: the things that make common lisp so good for a lone dev are what make it hard for larger projects and most projects nowadays have multiple contributors. I wouldn't start a startup on common lisp today unless you were trying to do something truly novel and your team was all seasoned and experienced devs. throwing a bunch of vibe coding juniors on common lisp is a recipe for disaster while you might make it to a series A using a language like go.
Personally, I love elixir as I think it strikes a really good balance. My team is all older programmers. Our youngest guy is 32 and we have all developed a pretty good intuition for maintaining a descent code base.
> Does it only work on source codes or can I distribute a binary and let my users debug the code like this? Should I distribute the 'image' for it to work?
I wouldn't hand it to the end user but paul grahm famously did cowboy debugging on live servers. A user would cal complaining of a error and paul could go in and patch it in real time while observing the runtime of the system the user was on.
I think it goes without saying that that was a different time and we def can't do that kind of thing today.
> And is the fix temporary (until the program dies) or permanant?
you patch teh code and reload it into your running vm. so its permanent.
Both CL and Elisp are arguably more functional than Javascript in several key ways - Immutable data by convention, First-class function from the start (js added this later), powerful higher-order function are more idiomatic, lexical closures, FP culture that goes back decades. JS has caught up in some aspects - arrow functions, array methods, const, libs like Rambda.
I think, Lisp in general is very flexible - you can write imperatively, or you can do more FP; if you need object-orientation - you have it, polymorphic dispatch - sure why not?, etc., etc.
What? Functions can be passed as arguments? Check! Returned from functions? Check! Stored in variables? Check! Lisp-2 just means functions and vars live in separate namespaces, that's all. In every other aspect they are first-class.
As the sibling says, CL can be written in most any style. Which, I think it is fair to say for any general programming language? The book Exercises in Programming Style highlights that. That said, CL feels far friendlier to the various styles than other languages, to me.
CL enables many paradigms of programming, including functional one and imperative. Currently the most popular way of programming among CL programmers is OOP with CLOS.
And that's before going into libraries like SERIES or iterate. There are, of course, benefits and disadvantages (readability, performance, some CL implementations don't do TCO,...) to every option, but generally CL lets you code in any way you want (you could even write some macros to let you write it using more infix or postfix style syntax, but I don't see the appeal of doing so).
It's hard to predict. There's a nonzero possibility that in that world, developers would have rejected the Netscape scripting solution, embraced the alternative that VBScript support in IE briefly represented, and we'd either be in a world where Microsoft dominated the web because only their browser did the fancy stuff that web 2.0 ended up needing to support ecommerce... Or where a couple of mud-pit-fight court cases had resulted in a vbscript-alike being the lingua franca of web scripting because Microsoft lost their exclusive control over it.
The JS backend to Gambit is now pretty mature. If you're willing to deal with Scheme, Gambit, and its FFI, you can live in that alternate "Scheme in the browser" universe even without WASM.
You say that as if FP is objectively superior to the imperative style, but as someone who's done both, I still find FP style like "swimming against the river"—if my brain thinks in steps and iterations, why do the mental gymnastics to convert that into recursion?
FP is principally about function composition, folds and zippers. I still find myself thinking in terms of iteration, it's just not expressed as a for-loop. Instead, the iteration conditions are expressed by the composed function which builds a list, and the body of the for-loop is expressed by the composed function applied to the members of the list.
for(int i = 0; i < N; ++i) { ... }
becomes
foldl (fn (i, acc) => ...) 0 (range N)
It's technically recursion, but I don't really see any of it, and I don't really think about it that way.
Fair point! Programming paradigms aren't objectively superior - they're tools, and different people's brains work differently. Many problems are naturally iterative, and forcing them into recursive patterns can feel awkward. That said, some problems become much cleaner with FP approaches - data transformations, avoiding shared state bugs, or mathematical computations. It's worth having both tools available. use imperative when you think in steps, use functional when you think in transformations. Don't force one paradigm everywhere just because it's trendy or "pure."
But do give yourself this gift - even if you end up preferring imperative style for day-to-day work, learning Haskell or Clojure can be genuinely eye-opening.
It's like learning a foreign language - even if you never become fluent, it changes how you think about your native language. You'll start seeing patterns and abstractions you missed before, even in imperative code.
upd: sorry, only after posting it I noticed your "as someone who's done both". Just wanted to point out that here my suggestion is aimed not to you directly, but to a "proverbial" programmer, I used "you" in more general sense.
My only concern with this approach from an ecosystem standpoint is that runtimes (and more importantly, their standard libraries) can be expensive. JS is still the heavyweight engine that everyone running a browser already has installed; a world where the browser has to download a novel runtime per website is going to be hard on the end-user on the back of a low-bandwidth connection.
... but it doesn't have to be that way. Proper tree-shaking of libraries and smart caching of common resources should make it possible for that cost to get minimized or amortized.
I will definitely look at this in detail. I'm doing something similar with S7 Scheme (a scheme that is heavily Common Lisp influenced), and it's working really well. Getting the plumbing going was a fair bit of work, but it's a huge win to be able to reuse my domain-code engine across the browser, C++ apps, and in Max/MSP (through my OSS Scheme for Max extension). Writing music theory related domain code is much nicer in a symbolic lisp family language than in JS.
Ah, in an alternate world where Brendan Eich wasn't pressured by his superiors to make JS more Java-like, we could have had something like this as very normal.
I wonder how much faster that would have pushed the world into FP ideas. While sometimes I prefer the bracket/C syntax, I wonder how things would have evolved if JS was a lisp originally. Instead of things moving to TypeScript, would they be moving to something like typed Lisp or OCaml, or PureScript ?
I wonder if, in that world, Lisp would be the boring corporate language, and HN would dream of a world where object orientation (which is clearly superior) never had a chance to leap from academia to the mainstream, and hackers post their niche flavors of Java and Smalltalk here.
Well, that world would also have CLOS - maybe the AMOP would be treated with the same reverence as the GoF design patterns book... ;-)
this article discussing how closure creation is disguised OO (and vice versa) might interest you.
https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
Even discussed here a couple times:
https://news.ycombinator.com/item?id=33676959 - November 2022, 64 comments
https://news.ycombinator.com/item?id=9363635 - April 2015, 45 comments
Is CL really particularly more “functional” than JavaScript? I don’t know CL but I know it bears some passing similarity to Emacs Lisp, which is usually written in a pretty imperative style. Sure, it has first-class closures but so does JS.
I kind of agree, but in the interest of discussion: even if CL isn't necessarily a more functional language in practice, culturally it's got a long history of being more functional. It took something like a decade at least for people to widely recognize to how elegant (in its quirky way) JavaScript could be. Just as a point of comparison (I'm sure the idea goes further back) PAIP - one of the definitive CL books - was first published in 1991 and encourages pure functions and immutability wherever possible.
Devs in the 90s were handed a language that looked like a weird Java and so they programmed it like a weird Java. If they were handed a language that looked like Lisp instead, maybe they would have made their way to SICP that much sooner.
> ... culturally it's got a long history of being more functional
Sure, but CL also culturally has a long history of macro-ridden code that make it harder to understand other people's code.
We already suffer from dozens of JS frameworks. Just imagine what it would look like under a CL-dominant world...
CL is the Ditto (pokemon) of programming langauges. It commits to nothing and does everything better than you'd expect. The problem is its very much a lone warrior type of language. you can attain great productivity due to macros and just how maleable it is but it makes it near impossible to get a team to work together on it without very extensive styling and conventions strictly adhered to by the team. In a way, you could say its a direct influence to go, in that the go team saw everything common lisp did and decided to do the opposite.
> It commits to nothing and does everything better than you'd expect.
Idk man, every time someone makes that claim my immediate reaction is: "what's the catch?". I much rather use 5 tools designed for specific purposes than general-purpose tools that are 50% good at 5 tasks.
the catch is that the langauge is so maleable that no two lisp codebases look the same. Makes it very difficult to establish broader idioms. But in terms of what it cando, its got ridiculously good runtime speed for how dymanic it is and the debugger is one of the best around. you can literally pause on an exception, rewind, fix your code and continue from where you left off.
I love the restarts system but the fact that the industry as a whole chose other approaches makes me wonder if there's something the "wisdom of the crowds" knows that I'm not aware of.
> you can literally pause on an exception, rewind, fix your code and continue from where you left off.
Does it only work on source codes or can I distribute a binary and let my users debug the code like this? Should I distribute the 'image' for it to work?
And is the fix temporary (until the program dies) or permanant?
> I love the restarts system but the fact that the industry as a whole chose other approaches makes me wonder if there's something the "wisdom of the crowds" knows that I'm not aware of.
The restart system is complex, harder to implement, and harder to reason about (it has more "spooky action at a distance", much of it determined at runtime and not compile time).
The "wisdom of the crowds" will generally favor systems that are either:
1. Easier to implement (including sustainment work in the future)
2. Easier to use (or reason about in this case)
Sometimes you get things that are both, but it's often not possible (or feasible) to find or make systems that are both easy to use and easy to implement.
Checked exceptions and explicit error returns are one of those things that happen to provide both (1) and (2) (sort of on 2: often more upfront work, but better reasonability). They're easier to implement for language developers (everything is known at compile time, there is less needed in terms of runtime support especially for explicit error returns), and they're easier to create static tooling for which helps users (programmers). Even without tooling, the explicitness and locality of information makes them more reasonable.
Unchecked exceptions are harder to implement (for instance, the need for handling cleanup as you unwind the stack, which could happen at any point in a function's execution), and they are harder to build static tooling for and harder for programmers to reason about. Common Lisp's conditions and restarts are even harder on all fronts.
This isn't a bad thing, it's a powerful tool. But it means that it won't be mainstream once easier alternatives come along. All the wisdom of the crowds has told us on this is that checked exceptions and explicit error returns are easier. Not that one is better or worse than the other.
> makes me wonder if there's something the "wisdom of the crowds" knows that I'm not aware of.
As I alluded to earlier, its really hard to scale a dev team when the language does nothing to keep you on the rails. As an engineer, I hate go for its lack of abstractions and verbosity. As a CTO, I can appreciate that its trying to reduce the friction in making sure all code looks familiar and that any engineer can be rotated into it. TLDR: the things that make common lisp so good for a lone dev are what make it hard for larger projects and most projects nowadays have multiple contributors. I wouldn't start a startup on common lisp today unless you were trying to do something truly novel and your team was all seasoned and experienced devs. throwing a bunch of vibe coding juniors on common lisp is a recipe for disaster while you might make it to a series A using a language like go.
Personally, I love elixir as I think it strikes a really good balance. My team is all older programmers. Our youngest guy is 32 and we have all developed a pretty good intuition for maintaining a descent code base.
> Does it only work on source codes or can I distribute a binary and let my users debug the code like this? Should I distribute the 'image' for it to work?
I wouldn't hand it to the end user but paul grahm famously did cowboy debugging on live servers. A user would cal complaining of a error and paul could go in and patch it in real time while observing the runtime of the system the user was on.
I think it goes without saying that that was a different time and we def can't do that kind of thing today.
> And is the fix temporary (until the program dies) or permanant?
you patch teh code and reload it into your running vm. so its permanent.
Both CL and Elisp are arguably more functional than Javascript in several key ways - Immutable data by convention, First-class function from the start (js added this later), powerful higher-order function are more idiomatic, lexical closures, FP culture that goes back decades. JS has caught up in some aspects - arrow functions, array methods, const, libs like Rambda.
I think, Lisp in general is very flexible - you can write imperatively, or you can do more FP; if you need object-orientation - you have it, polymorphic dispatch - sure why not?, etc., etc.
I object to the claim that a Lisp-2 has first-class functions.
What? Functions can be passed as arguments? Check! Returned from functions? Check! Stored in variables? Check! Lisp-2 just means functions and vars live in separate namespaces, that's all. In every other aspect they are first-class.
The separate namespaces mean that functions are considered as something fundamentally different from other values.
As the sibling says, CL can be written in most any style. Which, I think it is fair to say for any general programming language? The book Exercises in Programming Style highlights that. That said, CL feels far friendlier to the various styles than other languages, to me.
Link to book on Amazon: https://www.amazon.com/dp/0367350203
CL enables many paradigms of programming, including functional one and imperative. Currently the most popular way of programming among CL programmers is OOP with CLOS.
CL is pretty multi-paradigm. To give the boring 'double all numbers in a list' example:
And that's before going into libraries like SERIES or iterate. There are, of course, benefits and disadvantages (readability, performance, some CL implementations don't do TCO,...) to every option, but generally CL lets you code in any way you want (you could even write some macros to let you write it using more infix or postfix style syntax, but I don't see the appeal of doing so).It's hard to predict. There's a nonzero possibility that in that world, developers would have rejected the Netscape scripting solution, embraced the alternative that VBScript support in IE briefly represented, and we'd either be in a world where Microsoft dominated the web because only their browser did the fancy stuff that web 2.0 ended up needing to support ecommerce... Or where a couple of mud-pit-fight court cases had resulted in a vbscript-alike being the lingua franca of web scripting because Microsoft lost their exclusive control over it.
The JS backend to Gambit is now pretty mature. If you're willing to deal with Scheme, Gambit, and its FFI, you can live in that alternate "Scheme in the browser" universe even without WASM.
There's also Guile Hoots compiling directly to WASM.
You say that as if FP is objectively superior to the imperative style, but as someone who's done both, I still find FP style like "swimming against the river"—if my brain thinks in steps and iterations, why do the mental gymnastics to convert that into recursion?
FP is principally about function composition, folds and zippers. I still find myself thinking in terms of iteration, it's just not expressed as a for-loop. Instead, the iteration conditions are expressed by the composed function which builds a list, and the body of the for-loop is expressed by the composed function applied to the members of the list.
becomes It's technically recursion, but I don't really see any of it, and I don't really think about it that way.Fair point! Programming paradigms aren't objectively superior - they're tools, and different people's brains work differently. Many problems are naturally iterative, and forcing them into recursive patterns can feel awkward. That said, some problems become much cleaner with FP approaches - data transformations, avoiding shared state bugs, or mathematical computations. It's worth having both tools available. use imperative when you think in steps, use functional when you think in transformations. Don't force one paradigm everywhere just because it's trendy or "pure."
But do give yourself this gift - even if you end up preferring imperative style for day-to-day work, learning Haskell or Clojure can be genuinely eye-opening.
It's like learning a foreign language - even if you never become fluent, it changes how you think about your native language. You'll start seeing patterns and abstractions you missed before, even in imperative code.
upd: sorry, only after posting it I noticed your "as someone who's done both". Just wanted to point out that here my suggestion is aimed not to you directly, but to a "proverbial" programmer, I used "you" in more general sense.
WebAssembly is about an improved Developer Experience. It lets us write in the languages we like :)
I can't say how many times I've reinvented pieces of Common Lisp to do my job. Now I want to start a side project with this.
My only concern with this approach from an ecosystem standpoint is that runtimes (and more importantly, their standard libraries) can be expensive. JS is still the heavyweight engine that everyone running a browser already has installed; a world where the browser has to download a novel runtime per website is going to be hard on the end-user on the back of a low-bandwidth connection.
... but it doesn't have to be that way. Proper tree-shaking of libraries and smart caching of common resources should make it possible for that cost to get minimized or amortized.
I will definitely look at this in detail. I'm doing something similar with S7 Scheme (a scheme that is heavily Common Lisp influenced), and it's working really well. Getting the plumbing going was a fair bit of work, but it's a huge win to be able to reuse my domain-code engine across the browser, C++ apps, and in Max/MSP (through my OSS Scheme for Max extension). Writing music theory related domain code is much nicer in a symbolic lisp family language than in JS.
I will always push Dylan Beattie's talk about this exact thing!
https://www.youtube.com/watch?v=8JOD1AQGqEg&t=2358