←back to thread

110 points jackdaniel | 1 comments | | HN request time: 0.201s | source
Show context
adamddev1 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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. Jtsummers ◴[] No.44977611[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.

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.