Earlier quoted context omitted.
IMO if we look at Lisps today the question looks more like: SBCL, Chez Scheme, Racket or Clojure. Common Lisp and Racket are Lisp-2s but honestly, the namespace thing seems like a minor difference compared to all the other features that differentiate them.
[Racket is a lisp-1.]
A Road to Lisp: Which Lisp
81–90 of 180 posts
Re: A Road to Lisp: Which Lisp
#82Re: A Road to Lisp: Which Lisp
#83Re: A Road to Lisp: Which Lisp
#84Earlier quoted context omitted.
Except that CPython still misses on (compile .....) part, indeed holding the industry back.
it compiles to bytecode but the bytecode engine is not that fast. i had a phase when I was using PyPi a lot for branchy "old AI" kinds of workloads and felt it was an easy win but since then it has been either numpy or PIL or pytorch doing the heavy lifting or scripty stuff like uploading files to S3 where performance doesn't matter a lot. I will grant that Common Lisp can be compiled to run amazingly quickly!
This is how https://github.com/marcoheisig/Petalisp#why-is-petalisp-writ... and https://github.com/numcl/specialized-function can exist.
Re: A Road to Lisp: Which Lisp
#85I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…
Working with Clojure is an absolute delight. It strips down all the dogma and let's you deal with the "business logic" as if you're cooking steak using no BS ingredients - meat is meat, herbs are real, stove is hot.
Why would I ever choose bash for writing anything slightly more complex than simple redirection, when I can do things in way better fashion with babashka. Why would I wrestle a YAML CI pipeline that only fails on push, when I can drive the whole thing from a babashka task file, run each step locally in the REPL, and actually debug it?
Why would I ever deal with Lua, if I can't even format it for "readability" - no matter how I do it, it just looks darn ugly, and luafmt often makes it worse. Why, if I can just slash down dozen lines of Lua boilerplate compressing it into a three-liner Fennel macro? With Fennel, I can interactively poke through elements of my WM through Hammerspoon on Mac, and that's just bananas.
Why would I ever deal with JSON, when EDN is almost twice as compact and far more readable - I can align things and treat data as a literal table. Besides, I can group, sort, filter, slice, dice, salt & pepper that data easily, without ever leaving my trusted editor.
Why would I choose to build a web-scraper in Python, when I can use nbb driving Playwright and go through selectors interactively, directly from my editor, as if it is a devtools console. And I don't even have to restart anything, deal with state changes, etc.
How can I abandon Emacs where I can just open a scratch buffer, type some Elisp and change the behavior of my editor, my WM, my OS and even things on remote computers. No other text editing environment works the way Emacs does - nothing even comes close. It feels like playing a video game, where my controller in my editor.
Why would I write Flutter UIs in Dart, fighting the widget-tree ceremony and endless build() boilerplate, when ClojureDart lets me express the same tree as plain data and hot-reload it interactively? The layout is just nested maps and vectors.
Why would I reach for C when I need to embed a small, fast scripting layer. Text parsing alone would be a regex nightmare elsewhere.
Why would I bolt a templating engine onto HTML strings, when Hiccup makes markup just vectors - so my views compose, filter, and generate like any other data, no special templating DSL to learn
And with all sorts of different runtimes and dissimilar Lisp dialects, it still feels as if you're working with the same language. The mental overhead when switching is so negligible. While switching between just JS and TS - which are supposed to be of the "same family" - feels quite annoying. Despite the fact that I've put years into those - far longer than any Lisp I've ever used.
Sure, nothing special about Lisp at all. Except that practicing Lisp can actually make you a polyglot. You'd realize that it isn't syntax that makes a programming language, but runtime and semantics do. After years of dealing with different PLs, I lost a preference for one specific language - I'd choose the runtime best suitable for the task, and then see if I can bolt Lisp on top of it. And these days, it feels like there isn't a platform left where you can't meaningfully do things via Lisp.
Re: A Road to Lisp: Which Lisp
#86I'm going to take the opposite position that there is much less special about Lisp than people think. Like I have met so many programmers that travel around like itinerant martial artists looking for true functional programming and they never find it. To be specific, you can work all of the examples in Graham's On Lisp in Python except for one of the last chapters where he implements continuations that really need ma…
The real thing with CL is that the entire language is available during parsing and macro expansion and that users can hook into these steps to influence them. No artificial limitations like you get in C++'s consteval, you can do everything and anything without having to use a crappy DSL to do it.
Also, I've never found SBCL slow to compile. Have you?
Re: A Road to Lisp: Which Lisp
#87I have a work-in-progress called Modus. 100% written by Claude, so take that however you will. The current release boots on a Raspberry Pi Zero 2 W. The next release (unreleased in the pipe for ~ months) is standard Common Lisp on bare aarch64 (pi) and x64 (qemu for now), with linux aarch64 and x64 command line interfaces à la sbcl. https://github.com/modus-lisp/modus Since you can't use an OS by itself, I've rounded…
Re: A Road to Lisp: Which Lisp
#88I really wanted to Lisp as a main programming language, and sometimes I still do. I just find readability such a hurdle regardless of how long I used it. I didn't find that it ever became as natural as the other group of programming languages. I find a procedural style of programming so much easier to reason about, both when writing and reading. Either way, I'm really happy I took some time to learn it and use it a l…
I've had the same complaints when I started. I think, realistically, every programmer who's learning Lisp after getting experience in a bunch of other languages has to deal with that. The mental overhead feels real. Yet, after a while, there's some psychological threshold - Lisp starts feeling more intuitive. At some point, there's just no turning back - nothing ever will feel again more readable than Lisp code. It's just like riding a bike. Once you "get it", there's just no way to "unget it" back.
Re: A Road to Lisp: Which Lisp
#89Re: A Road to Lisp: Which Lisp
#90Earlier quoted context omitted.
I particpated in a Clojure reading group for "Getting Clojure" back around 2017. Having the entire JVM ecosystem available, is absolutely a great benefit. I even fooled around with ClojureScript a bit. David Nolen is great at making the case for both.
Now there's Jank too, the first time a Lisp dialect has reached into native world since Clasp. The way it interops Clojure with the LLVM is unprecedented.
I've already got enough of JVM compatibility to run Ring apps, and have some fun libraries like a Reagent style library on top of GTK https://yogthos.net/posts/2026-07-02-jolt.html