Reminder, HN is built/runs-on a dialect of Lisp (Arc).
On a single server.
On a single core.
Why Lisp?
71–80 of 339 posts
Re: Why Lisp?
#72> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…
> they have to learn Inhouse Lisp?
Is this much different from selecting a particular vendor deployment stack, such as react native, or a particular GUI toolkit such as Qt?
So.. now I don't just have to know C++ I have to know C++/Qt, or not just JavaScript but JavaScript/React?
Re: Why Lisp?
#73Appreciating what Lisp is capable of doing (think macros), and having worked through SICP some twenty years ago, and after having tried to make a deep dive in CL and Emacs Lisp two years ago, I come to the conclusion that there is no silver bullet in Lisp-land. Python is a good enough Lisp, as Peter Norvig has concluded. And it’s got all batteries included. Ain‘t nothing it can’t do. Building websites, doing maths, a…
>> except building compilers and OSes
SBCL is written in Lisp, yes? Except the runtime, which is C + asm.
I've heard people wrote some OSes in the past, like Genera. Or if you prefer recent attempt, try https://github.com/froggey/Mezzano. Never tried it, though.
Re: Why Lisp?
#74They link to "these years in Lisp" from 2018, here's 2022 in review: https://lisp-journey.gitlab.io/blog/these-years-in-common-li...
Re: Why Lisp?
#75> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…
> they have to learn Inhouse Lisp? Is this much different from selecting a particular vendor deployment stack, such as react native, or a particular GUI toolkit such as Qt? So.. now I don't just have to know C++ I have to know C++/Qt, or not just JavaScript but JavaScript/React?
Qt and React have been used for years by lots of people, so there's a lot of knowledge out there about them, their designs are more general-purpose and refined, and you're likely to have encountered them before.
Re: Why Lisp?
#76The article seems like mostly about Common Lisp, but how many of the points are applicable to rest of Lisps? (Scheme, Emacs Lisp, Janet, etc)
Racket has mediocre interactive features or so I hear: https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1...
> no condition/restart but just print you a trace, and little runtime inspector/debugger support
CL really was built with interactive support from the ground up.
I don't think Janet has many?
Re: Why Lisp?
#77The article seems like mostly about Common Lisp, but how many of the points are applicable to rest of Lisps? (Scheme, Emacs Lisp, Janet, etc)
I find most of it applies to Clojure, although being a younger language there is no code from 30 years ago to run. Based on the stability I’ve seen so far, it wouldn’t shock me if the Clojure code I write today still works 30 years from now.
Edit: There are some nuances of interactive support Common Lisp has that Clojure lacks, but I find Clojure supports interactive development much better than other languages.
Re: Why Lisp?
#78> The developers of Lisp give you the full powers that they had to develop the language. So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete? > Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation You could say the same about Java and 2…
> So someone joining the project doesn't just have to learn Lisp, they have to learn Inhouse Lisp? And the abstractions provided by modern languages are woefully incomplete?
Yes. To both.
All programming involves building up sets of abstractions that make sense to the domain. A new project usually means a whole new load of abstractions.
If the language is opinionated about that, there's a good chance they'll be similar to other projects. Python, Java come to mind. C++ is heading in that broad direction.
Most languages make application abstractions and language abstractions look different. Sometimes the standard library looks deliberately different as well. This seems to be the popular path.
Common lisp has an inconsistent stdlib. Scheme has a small one. Both draw a distinction between builtins (which get weird indentation and syntax highlighting) and functions, but it's not as big a visual distinction as other languages. Both let you add a function which normally looks like other functions at the call site but has weird semantics and the special name macro. This is approximately making extensions look the same as builtins.
Mixed with that, there's a credible risk of having limited continuations, or ideally delimited continuations, which are a complicated control flow construct. There's some risk of having first class environments. Also the character stream might get munged by reader macros before anything happens to it. You will have the compiler available at runtime and probably have weird phase separation hooks.
If you combine leaky syntax abstraction (the macros), reified continuations and environments you get something very expressive with interesting composition challenges for greater than zero developers.
The enterprisey lisp, clojure, drops a lot of power and adds a lot of convention.
Kernel fixes the inconsistency in macros. It also goes with first class environments, which are the sane thing to do for module systems. I don't remember if it has reified continuations.
The lambda calculus with environment style symbol lookup is a really nice core for a programming language. Lisp is about as close to that as any.
Re: Why Lisp?
#79> On the other hand, Lisp code written some 30 years ago will most of the time, without issue, work on a modern Common Lisp implementation. Yeah, just like Perl. Or Latin. No one uses them, these are dead languages that belong to a museum. It can be fun to study them and you definitely should if you want to be well-educated and know the history behind the modern world, but that's it.
The irony of this comment is that HN is written in Lisp.
I thought HN was written in Arc. I don't think the interoperability between Common Lisp implementations extends to Arc.
Re: Why Lisp?
#80> When you have a running program you can compile functions, redefine classes, etc. all while the program is running. You are changing the internal state of the image. This can surely be convenient in certain cases, however most of the times I find myself playing around with unit tests rather than with a single running process. Unit tests are small and fast so I don't even notice any inconvenience with the traditiona…
Best of both worlds: write unit tests with an interactive debugger o/
Tell the test runner to not catch errors and let them pass through up to the debugger. Have a test fail, get the debugger, go to the buggy line (without quitting the debugger), fix the bug, compile the function with a keystroke (yes, one function), come back to the debugger, restart not the full operation, but the function call, the debugger frame where the error happened, and see the test succeed.
You ran the test exactly once and fixed everything in the process, very quickly. This is exactly what we do everyday with the debugger, with trivial or complex code, with unit tests or regular code.
An example: https://www.youtube.com/watch?v=jBBS4FeY7XM not with unit tests, it's an example on how to restart a precise frame, how to avoid re-running everything.