←back to thread

Show HN: Using Common Lisp from Inside the Browser

(turtleware.eu)
110 points jackdaniel | 1 comments | 21 Aug 25 12:08 UTC | HN request time: 0.206s | source
Show context
adamddev1 ◴[21 Aug 25 13:43 UTC] No.44972696[source]▶
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 ?

replies(5): >>44973351 #>>44973702 #>>44976138 #>>44976751 #>>44977298 #
umanwizard ◴[21 Aug 25 15:05 UTC] No.44973702[source]▶
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.
replies(6): >>44973781 #>>44973976 #>>44974501 #>>44975807 #>>44976563 #>>44984186 #
cultofmetatron ◴[21 Aug 25 18:49 UTC] No.44976563[source]▶
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.
replies(1): >>44976735 #
behnamoh ◴[21 Aug 25 19:03 UTC] No.44976735[source]▶
> 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.

replies(1): >>44976796 #
cultofmetatron ◴[21 Aug 25 19:08 UTC] No.44976796[source]▶
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.
replies(1): >>44976831 #
behnamoh ◴[21 Aug 25 19:12 UTC] No.44976831[source]▶
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?

replies(2): >>44977168 #>>44977611 #
1. cultofmetatron ◴[21 Aug 25 19:45 UTC] No.44977168[source]▶
> 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.