The Liberating Experience of Common Lisp

Lisp really is an eye-opening experience when learning to structure programs and computations. Stumbling on Lisp in college was a fascinating experience for me in particular because I had been raised around C++ and Java, and my programming life up to that point had been a struggle understanding how to abstract a program into objects and how to build those objects' interfaces.

Once I started down the path of functional programming and Clojure, it became clear in retrospect that "objects" as C++ and Java envisioned them were poor fits for most problem domains, which is why their purpose never clicked in my head. Reducing data down to...well, data, and methods down to functions, and programs down to pyramids of expression calls made everything about program structure click in my head. Functional, expression-based style was FAR more intuitive to my brain than stateful object style. I now try to lean heavily into expressions and referential transparency no matter what language I use, though some languages make it easier than others.

Funnily enough, C program structure came much more naturally to me than either C++ or Java. Maybe because it's easy to decouple data from operations on that data, even if stateful. Hard to say.

Having programmed professionally in 36 languages, I must agree with this. I am having so much fun with Lisp, that I am not likely to go back.

> Often developers say how you can make a mess of a Common Lisp codebase because of such freedom it provides. But isn’t that the same with any language?

There is a story about the code behind the terminal interface for Tops-10 for the PDO-10. It had been tweaked over the years adding various features, such as using control-T to see what was happening in the running program. Many attempts were made to rewrite it, but it was so intertwined, that whoever tried fixing it gave up.

Three things are killer features for me with the slime+emacs running sbcl. First is that you can see the underlying source for anything down to the lisp implementation, e.g. the definition of 'macrolet'.

The second thing is if there is an error, it displays the stack with the ability to see what the local variables are in any function on the stack.

The third thing is that one can patch a running program, either once a breakpoint ('break) is encountered, or by doing control-C at the repl. And then resume it.

It is also fun that SBCL is unreasonably fast. It compiles itself in 2m15s. I am pretty sure that gcc/clang/llvm take longer than that and also likely Rust.

I have developed a habit of using s-expresions for lots of things, such as configuration files, and web page representations. I blame paredit and lisp for this tendency. See https://github.com/wglb/configuration-r

Two books, for beginners and experts:

- A Gentle Introduction to Symbolic Computation. Get both the book and the figures.

https://www.cs.cmu.edu/~dst/LispBook/

Paradigms of Artificial Intelligence Programming

https://github.com/norvig/paip-lisp

https://unglueit-files.s3.amazonaws.com/ebf/59f74a93bbc1435c...

Get SBCL as the compiler/interpreter, it's the fastest FLOSS one.

Portacle has everything to begin with minus the books.

https://portacle.github.io/

This is exactly why I exclusively write Perl, C, and Lisp, simply they are fun to write, and provide me with the capabilities to feel powerful as a developer. Most software written these days lands in languages that make me feel like a drone, endlessly fighting a system in place or a pattern for some arbitrary theoretical gain that is never realized in the real world anyways, OOP, Type-Systems, FP, whatever, why would I willingly commit myself to someone else's idea of what code should look like?

On side note, they say that 80% of developers are unhappy, do we think that languages have a big part in this?

https://survey.stackoverflow.co/2024/

I do web dev now, but it reminded me of good times coding in Julia.

Like I once wanted to have my own syntax for querying a SQLite, so built my own ORM. The query syntax is defined in like 50 lines of code. Doc for it here [1]

1. https://asjir.github.io/FunnyORM.jl/dev/#FunnyORM.TableQuery

I can relate. I read Graham's book on Common Lisp more than 20 years ago and was entranced.

But opportunities to use it in the day job are few and far between, and I would have qualms about recommending it, in most contexts. For a lot of purposes, its libraries are just nowhere near as good as Python or JavaScript or Java. And some of its superpowers (macros!) can also be used really, really badly.

There was an essay about Lisp being a "language for smart people" that captured some of what would give me pause. On average, most shops have average people (for that occupation/industry). Not sure Lisp is the best solution for that context.

I'm a big fan of lisps, and haven't played sufficiently with rust to have an opinion -- but I will note that the benefits of a sophisticated type system is qualitatively different from, say, the statically-typed environment of C or Objective-C. The comparison I make when thinking about CL is something like Haskell or Elm, which /do/ have that feel of "if it compiles, it works". Without that, I do have the feeling of working without a safety-net that pushes against that sense of freedom that dynamically-typed languages like CL otherwise offer.

(Obligatory mention here of Coalton, which is an experiment in creating that sense of security within a CL paradigm: https://github.com/coalton-lang/coalton )

Am I the only one who just bounces off the ecosystem? I don't mean emacs/slime/sbcl, it's once you get beyond that.

In my most recent foray I wanted to give roswell, qlot, and quicklisp a proper try, because I really want to find the Right Way to consume dependencies with proper version management. It's what I'm used to in just about every other context. But the version of qlot you get through roswell is old, nothing in that stack is doing versioned dependency resolution, and despite claims of stability, SBCL and ASDF seem to have had incompatibilities recently that'll trip you up if you happen to install the wrong thing, so you don't get Clojure's "code from a decade ago just works" effect.

What have I missed? It feels like I'm holding it wrong.

Apologies for donning my grumpy old man hat.

I like CL as much as the average dev who's dabbled with it on weekends but can't find anyone to pay me to use it, but...this essay really adds so little to the conversation about it. There's not an awful lot explicitly wrong in it per se, but people have been writing these little puff pieces on their blogs about Lisp for (at least) twenty years now. This checks all the usual boxes: "it's so powerful and liberating", "working in an image on a living system is amazing once you try it you'll see", "critics are wrong you can write unmaintainable code in any language", etc.

OP hasn't even really used Lisp in anger, yet: "my next project is being built with it". I'd be much more interested in seeing a postmortem after that - "Ten Years Building a Major Piece of Software in Lisp" - with some actual self-reflection, rather than just a regurgitation of the usual talking points.

Similar experience here... python/typescript during the day, Clojure at night ;-)

Shameless plug: just yesterday I published a step-by-step code walkthrough hoping to convey my "Clojure way" of modeling:

https://neuroning.com/boardgames-exercise/

It really echoes my first memories of personal computers.

You powered it on, and it landed you in a BASIC environment. Apple IIs, C64’s and Ataris all had a full-screen editor environment where you could type code, run it, pause it, inspect variables, and continue running. It wasn’t LISP, sadly, but it was great as an introduction and moving to “more professional” environments and tools took away a great deal of freedom away from us.

I wish this kind of comparisons actually would look beyond Emacs, into Allegro, LispWorks, Clozure CL.

A PG article about "doing what you love" was recently shared and discussed on HN [1], and I think a lot of the same logic applies. The nature of a job is that someone is paying you to do what they want you to do. If we're talking about what makes you happy in your free time, then sure, learn any obscure language that appeals to you. If you find something cool that you can do in CL and nowhere else, that's an amazing opportunity. If you just happen to think that life is too short to use a practical, established language, then I don't want career advice from you.

[1] https://news.ycombinator.com/item?id=41687176

> How long before Copilot is able to write all the code any Go developer now writes by hand?

A long time ago I read someone saying "Lisp is the only language where I spend more time thinking than typing". Recently, when I was telling ChatGPT what logic I wanted written on what data structures, I realized the same was true about having an LLM write any other language.

One minor point mentioned: I find it odd how many great PL designers I’ve known are hostile to learnings from other languages. Maybe because they field a ton of naive “why can’t A do what B does”. But languages are similar in many respects, and there are a great many lessons to share across.

Ykymg

Jheng

Worrying that Swift is getting worse, now that it's been adopted by Ladybird