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".

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 :)

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:

  (defun calculate (instructions)
    (reduce
     (lambda (result op-value)
       (destructuring-bind (operation value) op-value
         (case operation
           (:add (+ result value))
           (:subtract (- result value))
           (:multiply (* result value)))))
     instructions
     :initial-value 0))

  (calculate '((:add 5) (:multiply 3) (:subtract 4))) ;; => 11

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 so it isn't.

Many things hold us back.

The industry has been so traumzatized by slow compiles that trading speed for extensibility doesn't sell to the people who create languages. 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.

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.

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.

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.

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.

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.

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.

I recently started looking at https://github.com/elle-lisp/elle . It's made with AI but has an interesting feature set.

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.

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?

CommonLisp really should evolve to update the language up to the modern standards and become more functional and better typed.

PSA: VSCode users deserve to use the OLIVE plugin (https://github.com/kchanqvq/olive).

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.

So many words to say: Scheme.

:)

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 came here to see Janet mentioned and I am a bit sad :)

https://janet-lang.org/

Choose any LISP, and the right LISP will choose you.

I wonder if Hylang is still alive.

All roads lead to Lisp

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

(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.

Racket's top dog in my book :)

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

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.