Since a few folks here recommended Common Lisp to me as the language that would "tick all my boxes", I've been doing a deep dive. Right now, I'm working through SICP again with DrRacket. The first time I worked through it with MIT Scheme MANY years ago. It's shocking how much I've forgotten.
What I like about this article is that it walks through the different "camps" of Lisp. Scheme is so intriguing to me because of how small it can actually be. I can build nearly any paradigm I want to exist. The problem is, if I were to actually go find a job where they were using a Lisp, (I hear those actually exist) they wouldn't want to use my "Result monad + match statement - railway pattern" that I've used from OCaml and Rust. So learning something that is truly "common" can make more sense.
As far as learning though, Scheme feels "just right". I've imposed a "no AI until I've found a working solution" rule that keeps my mind engaged. Couple that with a willingness to say, "I don't know that right now... I'll think about it throughout the day and maybe by this evening I'll have an answer".
For what it's worth, Scheme was the first programming class that I took at UIUC around 1995, as I recall.
I had used C++ for several years to make shareware games, so I took a test to challenge some programming courses. I vaguely recall doing well, but my advisor encouraged me to take them anyway. I'm glad that I did, because I had little understanding of theory.
Funny story: the instructor never mentioned that we could use more than one line of code. So every single piece of homework that I handed in, and every test, was one giant line of nested logic. Which worked better than one might expect, and completely changed how I wrote code from that point forward. That's how I made the connection a decade later that functional programming is akin to a spreadsheet, as are higher-order method chains and immutable variables.
I think of Clojure as being a layer above Lisp, sort of like how Swift might be considered a layer above Objective-C/Smalltalk. However, bare Lisp has problems around not quite giving enough out of the box. It's minimalist enough that developers end up reinventing the wheel for things that should probably be provided by a layer/library similar to Scheme or Clojure.
To digress, I feel that mutable variables and even monads are a code smell in functional programming since they can cause impurity. They're more of a crutch to ease conversion of code from imperative languages. However, monads can be useful to simulate every path through a program, sort of like superposition in quantum mechanics and SAT solvers. So they aren't necessarily bad, just taught incorrectly, probably because they're so hard to grok.
I'd vote to settle on a series of layers like Common Lisp -> Scheme/Racket -> Clojure/Elisp, with the final layer providing the intersection of features available from the most widely-used Lisp variants. Note that this is specifically to form a bridge from imperative languages, so research work might need additional DSL features brought forth from the Racket layer.
Edit: I forgot to mention that Scheme is a good fit for genetic algorithms, see books by John Koza (no affiliation). My feeling is that we haven't seen anything yet regarding what problems AI can solve, since it's having to do it the "bare hands" way with LLMs and pattern matching.
I can also recommend clojure. For me it has the best parts of common lisp and the best of the java ecosystem. But its also quite different from common lisp and scheme. Different enough to find some unique ideas.
Writing scripts using [0] Babashka is also really nice.
As a former Clojure dev (now just using Clojure in my spare time) I love Babashka. Michiel Borkent really nailed it with sci (Small Clojure Interpreter) and Babashka. Running a custom Clojure interpreter in a GraalVM compiled Clojure app is quite clever.
Now there are of course limitations to what you can do in terms of not supporting Java reflection or the full Clojure compiler. But I've made some nifty small scripts and convenience helpers with it. And the dev experience of making these scripts is so much nicer than trying to write bash scripts. The Clojure edn syntax is super simple, and the REPL connected editor let me rapidly test parts of the code just like with full Clojure apps.
I don't have experience with other lisps, but I can vouch for Clojure being very nice. The community was welcoming and friendly to newcomers when I started learning, I hope it still is. One thing I love about the Clojure ecosystem and community is the effort taken to never break libraries. I've looked at libraries I used some ten years ago, and the API is still compatible with code I wrote back then. There is very little churn. Maybe this is because the language is largely untyped and editors only partially check "types". Having breakages in libraries you consume once every couple of months would get really tiring in Clojure land. I'd imagine the same problems would present themselves in Common Lisp and others.
I love the Clojure community, it is the only one that usually talks about the host platform in a symbiotic way, not as if they would be rewriting everything into their favourite language, like in most guest languages communities.
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.
> the first time a Lisp dialect has reached into native world since Clasp.
What's that supposed to mean? Many (probably most if we only consider the non-toy ones) lisp implementations are "native" (compiling to native machine code, not interpreted).
On a related note, there's a cross-platform Common Lisp package, "Bike" https://github.com/Lovesan/bike, that lets you use .Net assemblies from Common Lisp.
I've used it a tiny bit at work (on Windows) and at home (on Linux), and ran into one issue with "out" parameters, but otherwise it works really well.
From my experience, to be happy I would need the perf of sbcl, the syntax, litterals and data structure of clojure, the begginer-friendlyness of drracket, the type system of ocaml, and the dev experience of rust.
Does that exist somewhere ? I hope jank gets there. Or maybe roc will.
At this point, given the progress and expectations of using LLM, writing code is going to be purely a hobby concern, like carving wood furniture became a hobby once you have Ikea.
That helped me to think about recursion, functional programming, and type driven development. After going through HTDP I was able to breeze through complex problems that were unsolvable before.
I'm surprised there's no call out highlighting Common Lisp and Clojure's "liveness" compared to Racket (and Scheme). Racket is "batch compiled" wherein CL and Clojure you're editing a live image.
I also might have written the Common Lisp example using reduce as well, which is in the standard library, but that's preference. Nice to have the option though:
For me the complete spec is the killer feature. You can learn Common Lisp in 1990 and write it the same now. As long as we can keep the compilers alive it will be forever.
It’s funny to me that it was critiqued for being “bloated” when now it looks like a focused minimal library.
Also, SBCL has some nice features specific to them, I'm sure it's the same for other implementations. So while there's a lot that's common between them all I find myself using a lot of platform specific functions.
Yes, but it existed before then (from 1984 on), and a large amount of code written for CL pre-standardization still runs without alteration or with minimal updates.
I'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 macros -- but this is basically the async/await facility that Python already has. The other examples use macros for performance but work fine with just plain functional programming.
React with hooks is an example of that kind of system at work -- the JSX transformation is a very simple shim you can put in front of the JS compiler and the hooks themselves are the kind of trick that On Lisp teaches you how to do.
On Lisp doesn't use the kind of tree-walking macros that really are unique to Lisp. And... the techniques in the Dragon Book for writing compilers are the real magic. If looking to Lisp as an old shiny keeps you from learning how to write compilers, it is holding you back.
I think the homoiconic thing leads people astray. There's a real tension that, for performance reasons, mainstream compilers aren't extensible, for instance you might want to write a
unless(X) {...} => if(!X) {...}
control structure in a new language and for something in Java that is really a production rule in the grammar, maybe a class to represent the unless block, and a rewriting rule that gets applied to the AST. If the compiler was designed to be easily extensible that would be less code than the POM file for the project. But it's not but it isn't.
Many things hold us back.
The industry has been so traumzatized by slow compiles that trading speed for extensibility. Also once you have the sophistication to make things like parser generators you know how to get things done with the terribly unergonomic parser generators we have and don't have a lot of empathy for all the programmers out there who might be using parser generators if any of them were built as if usability matters.
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!
Shut up and learn Common Lisp using Practical Common Lisp.
This would be my advice. Why? My own road was haphazard. Other books broaden your mind and teach you really cool tricks. This book gets you using lisp like you would say golang. But it still teaches you the lisp things and broadens your mind. Time spent choosing will be better spent reading this book. After that PAIP, On Lisp, SICP etc.
An Introduction to Programming in EMacs Lisp is also good for the first few chapters even if you don’t use emacs because you are given fundamental concepts of lisp that can be applied to the understanding of other dialects. It’s also free.
Learn you a Haskell (despite Haskell being not a flavor of list, they share similar DNA ) is great at understanding functional programming with lisp like languages.
I 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 little at some point.
Common Lisp code can be very procedural if that's what you want to do. The entire loop macro is basically importing Algol-styled procedural loops into Lisp.
Lisp really needs extensive structural editing tools IMO, and you really have to change how you think about reading source text and that can take longer than you might think. The best Lisp experience by far and away is LispWorks. That being said, I never found it to be to my tastes either. Too much focus on making tree-representations of programs the centerpoint, which isn't how my internal grammar works. I'd much prefer less explicit delimitation where it's not actually needed, but that's also incompatible with the goal of sexprs.
For me, the most effective way to read Lisp is to essentially forget the parentheses (I shadow them out in matching, low contrast colors) and go almost entirely by indentation. I find this makes it more similar to reading other languages, though granted not exactly the same.
You do have to keep up with the parentheses of course, but editor settings or extensions can make this automatic if not invisible.
> I find a procedural style of programming so much easier to reason about, both when writing and reading.
Then do that.
There's nothing stopping you from using pretty much any style of programming that you like. Or mix and match. Or evolve over time.
Loops, lists, arrays, structures. Simple iteration: dotimes, dolist, loop. If those are your bread and butter, then feast! CL will happily do that. That's what I do. I just don't think "functionally" when I do CL code, I'm just not there yet, so its unnatural for me, and not what comes spewing out of my fingers when I write code.
And it's "OK".
You don't have to use the other features of the language, but they're there if you want to dip your toe into it.
With CL, also, I tend to be really wordy on variable and function names. I'm really fond of kabob-case-for-identifers.
The funny thing about Lisp is that writing a Lisp interpreter is significantly fewer keystrokes than correctly installing Common Lisp and its tooling. The ratio of lisps to lisp programmers may actually be above 1.
The argument is: if you don’t have hygienic macros, a Lisp-2 is going to be less brittle than a Lisp-1.
The classic example is, imagine you have a function with a local variable called “list”, common enough. Now imagine you invoke a macro inside that function which generates a call to the built-in “list” function - also common enough. In a Lisp-1 without hygiene that breaks - your local definition shadowed the built-in; in a Lisp-2 or hygienic Lisp-1 you’re in the clear.
@nathan_compton, your sibling comment to what I'm writing now is [dead] (not [flagged]) but you're not shadowbanned, newer and older comments are still alive. I vouched for it but it's still [dead], you may want to reach out to the mods.
Ignoring all the other distinctions between lisps, the main difference between lisp-1 and lisp-2 (or lisp-n) is going to be how clean your code looks when you lean into the FP style. In a lisp-2 you'll need to do something like this:
(defun apply-twice (f x)
(funcall f (funcall f x)))
(apply-twice #'1+ 2)
Versus this with a lisp-1:
(define (apply-twice f x)
(f (f x))
(apply-twice 1+ 2) ;; assuming 1+ is defined
But there are so many other differences between the lisps in the two categories that this probably won't be the deciding factor for most people.
I am a strong proponent of Lisp 1, primarily because the distinction between functions and other types of values is artificial. Functions have first class semantics in Lisp 1 and Lisp 2, but Lisp 2 makes you denote them differently but in an inconsistent manner.
Lisp 2 advocates typically make a few arguments. One is that having a separate namespace for functions makes it clearer when you are using a function vs another value. The second is that the evaluator has less work to do when examining the head of a list - it needs only look in the function environment, not the full environment.
On the first subject I must disagree - you can bind a function to a regular variable and then use that variable everywhere (except in the car of a list representing a function call), so for most positions in a set of expressions you don't really get information about whether the object being denoted is a function or not.
I suppose the second point is somewhat valid, though I suspect if you benchmarked interpreters and compilers it would barely matter. As a person who favors functional programming with a lot of combinators, I find Lisp 2 introduces a lot of pointless noise in the syntax for no reason. And I fundamentally just don't see functions as significantly different sorts of values, so I find the syntactic distinction bizarre.
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.
Elisp::Emacs as AutoLISP::AutoCAD. AutoLISP was my first introduction to Lisp-style language. When I first started using it (1987) for macros in AutoCAD, I really had no idea what Lisp was. It was just a fun and easy way to automate AutoCAD.
When people have a lot of choices, that can create problems, because it's often the people with the least information trying to make that choice.
For instance "I'm new to Lisp, I want to try one..." is a person without a lot of background and information to make that choice. And they probably realize it and it makes them nervous about making that choice.
(Disclaimer: CL weenie) A decent and balanced writeup IMO. But it should really have contained the following:
Warning about the issues that come with ANSI CL's frozen spec (threads/sockets/unicode/extensible sequences/gray streams/etc... as extensions with a varying amount of support with compatibility layers often available to write portable-ish code, "bolted-on" CLOS never fully integrated) and its various rust spots, not just the good points.
Mention that CL has provisions for gradual typing (with limits) which are exploited by SBCL.
Scheme, obviously, along with the same warning as CL about pain of writing portable code that interacts with the OS (does it have compatibility layers like CL?) amplified by the R6RS vs unfinished R7RS-large mess.
A few words about the build system/third-party packaging situation and alternative implementations.
I 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.
Since you can't use an OS by itself, I've rounded out the Common Lisp environment with portable ssh client and server, web browser, and a bitcoin node. Framebuffer with VNC in the pipe
There is also MLs that have the same idea, but with less implementation, as a lisp is something you hack in a weekend. An working ML not, as it takes way more effort.
Lisps have many fantastic ideas, but are really hard to read. Lisp code is what we had before perl guys went "hold my beer".
I know its just syntax, and it usually does not matter, untill it does. I did some clojure a long time ago, and before that some CL, and god, i cant understand my own old code. Contrast that to some language that has syntax i can read it still, years later. Go being the prime example of write once, read a decade later.
I find Lisp much easier to read than most other languages. It is highly explicit syntax with very little ambiguity, especially if you have a little discipline about macros.
Since a few folks here recommended Common Lisp to me as the language that would "tick all my boxes", I've been doing a deep dive. Right now, I'm working through SICP again with DrRacket. The first time I worked through it with MIT Scheme MANY years ago. It's shocking how much I've forgotten.
What I like about this article is that it walks through the different "camps" of Lisp. Scheme is so intriguing to me because of how small it can actually be. I can build nearly any paradigm I want to exist. The problem is, if I were to actually go find a job where they were using a Lisp, (I hear those actually exist) they wouldn't want to use my "Result monad + match statement - railway pattern" that I've used from OCaml and Rust. So learning something that is truly "common" can make more sense.
As far as learning though, Scheme feels "just right". I've imposed a "no AI until I've found a working solution" rule that keeps my mind engaged. Couple that with a willingness to say, "I don't know that right now... I'll think about it throughout the day and maybe by this evening I'll have an answer".
For what it's worth, Scheme was the first programming class that I took at UIUC around 1995, as I recall.
I had used C++ for several years to make shareware games, so I took a test to challenge some programming courses. I vaguely recall doing well, but my advisor encouraged me to take them anyway. I'm glad that I did, because I had little understanding of theory.
Funny story: the instructor never mentioned that we could use more than one line of code. So every single piece of homework that I handed in, and every test, was one giant line of nested logic. Which worked better than one might expect, and completely changed how I wrote code from that point forward. That's how I made the connection a decade later that functional programming is akin to a spreadsheet, as are higher-order method chains and immutable variables.
I think of Clojure as being a layer above Lisp, sort of like how Swift might be considered a layer above Objective-C/Smalltalk. However, bare Lisp has problems around not quite giving enough out of the box. It's minimalist enough that developers end up reinventing the wheel for things that should probably be provided by a layer/library similar to Scheme or Clojure.
To digress, I feel that mutable variables and even monads are a code smell in functional programming since they can cause impurity. They're more of a crutch to ease conversion of code from imperative languages. However, monads can be useful to simulate every path through a program, sort of like superposition in quantum mechanics and SAT solvers. So they aren't necessarily bad, just taught incorrectly, probably because they're so hard to grok.
I'd vote to settle on a series of layers like Common Lisp -> Scheme/Racket -> Clojure/Elisp, with the final layer providing the intersection of features available from the most widely-used Lisp variants. Note that this is specifically to form a bridge from imperative languages, so research work might need additional DSL features brought forth from the Racket layer.
Edit: I forgot to mention that Scheme is a good fit for genetic algorithms, see books by John Koza (no affiliation). My feeling is that we haven't seen anything yet regarding what problems AI can solve, since it's having to do it the "bare hands" way with LLMs and pattern matching.
I can also recommend clojure. For me it has the best parts of common lisp and the best of the java ecosystem. But its also quite different from common lisp and scheme. Different enough to find some unique ideas.
Writing scripts using [0] Babashka is also really nice.
[0] https://babashka.org/
As a former Clojure dev (now just using Clojure in my spare time) I love Babashka. Michiel Borkent really nailed it with sci (Small Clojure Interpreter) and Babashka. Running a custom Clojure interpreter in a GraalVM compiled Clojure app is quite clever.
Now there are of course limitations to what you can do in terms of not supporting Java reflection or the full Clojure compiler. But I've made some nifty small scripts and convenience helpers with it. And the dev experience of making these scripts is so much nicer than trying to write bash scripts. The Clojure edn syntax is super simple, and the REPL connected editor let me rapidly test parts of the code just like with full Clojure apps.
I don't have experience with other lisps, but I can vouch for Clojure being very nice. The community was welcoming and friendly to newcomers when I started learning, I hope it still is. One thing I love about the Clojure ecosystem and community is the effort taken to never break libraries. I've looked at libraries I used some ten years ago, and the API is still compatible with code I wrote back then. There is very little churn. Maybe this is because the language is largely untyped and editors only partially check "types". Having breakages in libraries you consume once every couple of months would get really tiring in Clojure land. I'd imagine the same problems would present themselves in Common Lisp and others.
I love the Clojure community, it is the only one that usually talks about the host platform in a symbiotic way, not as if they would be rewriting everything into their favourite language, like in most guest languages communities.
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.
> the first time a Lisp dialect has reached into native world since Clasp.
What's that supposed to mean? Many (probably most if we only consider the non-toy ones) lisp implementations are "native" (compiling to native machine code, not interpreted).
On a related note, there's a cross-platform Common Lisp package, "Bike" https://github.com/Lovesan/bike, that lets you use .Net assemblies from Common Lisp.
I've used it a tiny bit at work (on Windows) and at home (on Linux), and ran into one issue with "out" parameters, but otherwise it works really well.
That's just crazy! (in a good way) I've been in software since 1998 and it's like I've just uncovered a whole new world.
Babashka is really nice indeed. Am hopeful for the C++ hosted Clojure dialect, Jank (https://jank-lang.org)
From my experience, to be happy I would need the perf of sbcl, the syntax, litterals and data structure of clojure, the begginer-friendlyness of drracket, the type system of ocaml, and the dev experience of rust.
Does that exist somewhere ? I hope jank gets there. Or maybe roc will.
At this point, given the progress and expectations of using LLM, writing code is going to be purely a hobby concern, like carving wood furniture became a hobby once you have Ikea.
So we might as well use fun tools :)
How to Design Programs with Racket was life changing.
https://htdp.org
That helped me to think about recursion, functional programming, and type driven development. After going through HTDP I was able to breeze through complex problems that were unsolvable before.
I'm surprised there's no call out highlighting Common Lisp and Clojure's "liveness" compared to Racket (and Scheme). Racket is "batch compiled" wherein CL and Clojure you're editing a live image.
CL also has pretty much arbitrarily extensible syntax:
- https://sr.ht/~dieggsy/whisper/
- https://dieggsy.com/json-literals.html
And could also be used to build languages, supporting more modern programming paradigms (though yes, I believe Racket does make this easier):
- https://coalton-lang.github.io/
I also might have written the Common Lisp example using reduce as well, which is in the standard library, but that's preference. Nice to have the option though:
I'd have used
instead, looks funkier =)Oh yeah, way more fun :) I just kinda saw CL in the Clojure and was trying to make it look like that.
For me the complete spec is the killer feature. You can learn Common Lisp in 1990 and write it the same now. As long as we can keep the compilers alive it will be forever.
It’s funny to me that it was critiqued for being “bloated” when now it looks like a focused minimal library.
It's small enough a single person could write a test suite for the whole standard.
Common Lisp wasn't standardised until 1994.
Also, SBCL has some nice features specific to them, I'm sure it's the same for other implementations. So while there's a lot that's common between them all I find myself using a lot of platform specific functions.
Yes, but it existed before then (from 1984 on), and a large amount of code written for CL pre-standardization still runs without alteration or with minimal updates.
I'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 macros -- but this is basically the async/await facility that Python already has. The other examples use macros for performance but work fine with just plain functional programming.
React with hooks is an example of that kind of system at work -- the JSX transformation is a very simple shim you can put in front of the JS compiler and the hooks themselves are the kind of trick that On Lisp teaches you how to do.
On Lisp doesn't use the kind of tree-walking macros that really are unique to Lisp. And... the techniques in the Dragon Book for writing compilers are the real magic. If looking to Lisp as an old shiny keeps you from learning how to write compilers, it is holding you back.
I think the homoiconic thing leads people astray. There's a real tension that, for performance reasons, mainstream compilers aren't extensible, for instance you might want to write a
control structure in a new language and for something in Java that is really a production rule in the grammar, maybe a class to represent the unless block, and a rewriting rule that gets applied to the AST. If the compiler was designed to be easily extensible that would be less code than the POM file for the project. But it's not but it isn't.Many things hold us back.
The industry has been so traumzatized by slow compiles that trading speed for extensibility. Also once you have the sophistication to make things like parser generators you know how to get things done with the terribly unergonomic parser generators we have and don't have a lot of empathy for all the programmers out there who might be using parser generators if any of them were built as if usability matters.
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!
Shut up and learn Common Lisp using Practical Common Lisp.
This would be my advice. Why? My own road was haphazard. Other books broaden your mind and teach you really cool tricks. This book gets you using lisp like you would say golang. But it still teaches you the lisp things and broadens your mind. Time spent choosing will be better spent reading this book. After that PAIP, On Lisp, SICP etc.
Piggy backing to apply more recommendations too.
An Introduction to Programming in EMacs Lisp is also good for the first few chapters even if you don’t use emacs because you are given fundamental concepts of lisp that can be applied to the understanding of other dialects. It’s also free.
Learn you a Haskell (despite Haskell being not a flavor of list, they share similar DNA ) is great at understanding functional programming with lisp like languages.
that's the book i learned with. it got me far enough that i was able to write two applications that i ended up using for several years.
Gambit Scheme (https://github.com/gambit/gambit) is a highly performant Scheme implementation (https://ecraven.github.io/r7rs-benchmarks/). Gerbil (https://cons.io) is built on top of it.
Both highly recommended.
Choose any LISP, and the right LISP will choose you.
I 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 little at some point.
Common Lisp code can be very procedural if that's what you want to do. The entire loop macro is basically importing Algol-styled procedural loops into Lisp.
that's the conclusion i came up with after learning common lisp. it didn't feel much different from what i had learned before.
Lisp really needs extensive structural editing tools IMO, and you really have to change how you think about reading source text and that can take longer than you might think. The best Lisp experience by far and away is LispWorks. That being said, I never found it to be to my tastes either. Too much focus on making tree-representations of programs the centerpoint, which isn't how my internal grammar works. I'd much prefer less explicit delimitation where it's not actually needed, but that's also incompatible with the goal of sexprs.
For me, the most effective way to read Lisp is to essentially forget the parentheses (I shadow them out in matching, low contrast colors) and go almost entirely by indentation. I find this makes it more similar to reading other languages, though granted not exactly the same.
You do have to keep up with the parentheses of course, but editor settings or extensions can make this automatic if not invisible.
(Heresy alert. Inb4 homoinconcity)
I do find that most of my lisp skills carry over to JavaScript quite well while allowing me to write imperative functions more fluently.
Prog blocks are pretty good. I wonder if another DSL could be better.
Maybe because Brendan Eich was tasked with "doing Scheme in the browser" before it pivoted to JavaScript.
Imagine what could have been...
> I find a procedural style of programming so much easier to reason about, both when writing and reading.
Then do that.
There's nothing stopping you from using pretty much any style of programming that you like. Or mix and match. Or evolve over time.
Loops, lists, arrays, structures. Simple iteration: dotimes, dolist, loop. If those are your bread and butter, then feast! CL will happily do that. That's what I do. I just don't think "functionally" when I do CL code, I'm just not there yet, so its unnatural for me, and not what comes spewing out of my fingers when I write code.
And it's "OK".
You don't have to use the other features of the language, but they're there if you want to dip your toe into it.
With CL, also, I tend to be really wordy on variable and function names. I'm really fond of kabob-case-for-identifers.
The funny thing about Lisp is that writing a Lisp interpreter is significantly fewer keystrokes than correctly installing Common Lisp and its tooling. The ratio of lisps to lisp programmers may actually be above 1.
Lisp interpreters are easy to write; a performant and standard compliant Common Lisp system is considerably harder to write.
I just wish a good IDE existed so I don't have to use Emacs. That's what made me drop lisp in the past.
I would be happy with (neo)Vim setup as well, but that was way behind Emacs and broken when I tried.
LispWorks - https://www.lispworks.com/
Thanks.
However, price for hobby user license at 750 USD is laughable.
as of now neovim works great with clojure, not sure about other lisps. vs code also.
I am/was mainly interested in Common Lisp. I might give Vim another try, that would be the best if it worked. I really don't like vscode
mine is a new IDE that's part of the Coalton project, but is meant to be used for Common Lisp as well: https://coalton-lang.github.io/mine/
I have not tried it, I'm an Emacs nerd.
So many words to say: Scheme.
:)
Perhaps, but Chicken? Guile? Chez? They're all pretty cool.
R5RS, R6RS, or R7RS?
R6RS.
Since this is the largest gathering of LISP users I have seen, I have a question.
Why prefer lisp-1 over lisp-2 or vice-versa?
The argument is: if you don’t have hygienic macros, a Lisp-2 is going to be less brittle than a Lisp-1.
The classic example is, imagine you have a function with a local variable called “list”, common enough. Now imagine you invoke a macro inside that function which generates a call to the built-in “list” function - also common enough. In a Lisp-1 without hygiene that breaks - your local definition shadowed the built-in; in a Lisp-2 or hygienic Lisp-1 you’re in the clear.
@nathan_compton, your sibling comment to what I'm writing now is [dead] (not [flagged]) but you're not shadowbanned, newer and older comments are still alive. I vouched for it but it's still [dead], you may want to reach out to the mods.
Ignoring all the other distinctions between lisps, the main difference between lisp-1 and lisp-2 (or lisp-n) is going to be how clean your code looks when you lean into the FP style. In a lisp-2 you'll need to do something like this:
Versus this with a lisp-1: But there are so many other differences between the lisps in the two categories that this probably won't be the deciding factor for most people.As someone who has used both kinds over many, many years: it really doesn't matter.
I am a strong proponent of Lisp 1, primarily because the distinction between functions and other types of values is artificial. Functions have first class semantics in Lisp 1 and Lisp 2, but Lisp 2 makes you denote them differently but in an inconsistent manner.
Lisp 2 advocates typically make a few arguments. One is that having a separate namespace for functions makes it clearer when you are using a function vs another value. The second is that the evaluator has less work to do when examining the head of a list - it needs only look in the function environment, not the full environment.
On the first subject I must disagree - you can bind a function to a regular variable and then use that variable everywhere (except in the car of a list representing a function call), so for most positions in a set of expressions you don't really get information about whether the object being denoted is a function or not.
I suppose the second point is somewhat valid, though I suspect if you benchmarked interpreters and compilers it would barely matter. As a person who favors functional programming with a lot of combinators, I find Lisp 2 introduces a lot of pointless noise in the syntax for no reason. And I fundamentally just don't see functions as significantly different sorts of values, so I find the syntactic distinction bizarre.
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.]
PSA: VSCode users deserve to use the OLIVE plugin (https://github.com/kchanqvq/olive).
All roads lead to Lisp
Another Lisp of note is AutoLISP.
Elisp::Emacs as AutoLISP::AutoCAD. AutoLISP was my first introduction to Lisp-style language. When I first started using it (1987) for macros in AutoCAD, I really had no idea what Lisp was. It was just a fun and easy way to automate AutoCAD.
I had forgotten about this. The last I saw this was 20+ years ago!
Adding and substracting 3D-objects was the same as in OpensCAD.
Strange they did not make OpenSCAD in AutoLISP-style.
I have to read the manual all the time, because I never learn the weird syntax of OpenSCAD for-statement.
Racket's top dog in my book :)
I came here to see Janet mentioned and I am a bit sad :)
https://janet-lang.org/
When people have a lot of choices, that can create problems, because it's often the people with the least information trying to make that choice.
For instance "I'm new to Lisp, I want to try one..." is a person without a lot of background and information to make that choice. And they probably realize it and it makes them nervous about making that choice.
See: https://en.wikipedia.org/wiki/The_Paradox_of_Choice
I wonder if Hylang is still alive.
There's also Rhombus now: https://docs.racket-lang.org/rhombus-quick/index.html
(Disclaimer: CL weenie) A decent and balanced writeup IMO. But it should really have contained the following:
Warning about the issues that come with ANSI CL's frozen spec (threads/sockets/unicode/extensible sequences/gray streams/etc... as extensions with a varying amount of support with compatibility layers often available to write portable-ish code, "bolted-on" CLOS never fully integrated) and its various rust spots, not just the good points.
Mention that CL has provisions for gradual typing (with limits) which are exploited by SBCL.
Scheme, obviously, along with the same warning as CL about pain of writing portable code that interacts with the OS (does it have compatibility layers like CL?) amplified by the R6RS vs unfinished R7RS-large mess.
A few words about the build system/third-party packaging situation and alternative implementations.
I 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 out the Common Lisp environment with portable ssh client and server, web browser, and a bitcoin node. Framebuffer with VNC in the pipe
That's pretty neat!
God help me if I fell down a hole like that.
I must say, however, that e.g. code like (compile-compound) is something only an AI can love!
i've spent decades reading and writing code. i just want something that works
Related:
A road to Lisp: Why Lisp
https://news.ycombinator.com/item?id=48845209
There is also MLs that have the same idea, but with less implementation, as a lisp is something you hack in a weekend. An working ML not, as it takes way more effort.
Lisps have many fantastic ideas, but are really hard to read. Lisp code is what we had before perl guys went "hold my beer".
I know its just syntax, and it usually does not matter, untill it does. I did some clojure a long time ago, and before that some CL, and god, i cant understand my own old code. Contrast that to some language that has syntax i can read it still, years later. Go being the prime example of write once, read a decade later.
I find Lisp much easier to read than most other languages. It is highly explicit syntax with very little ambiguity, especially if you have a little discipline about macros.