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.
A big piece of OO development is state management. If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - then OO is most likely the way to go. You can encapsulate that state management in one place rather than having it strewn throughout the entire codebase.
If you're doing information-oriented processing, whether it be a traditional batch process, or a decision-support system reacting in real time to incoming data - then functional is most like the way to go.
If you're doing corporate CRUD development, then just use JavaScript (assuming Web CRUD) and the popular CRUD framework du jour.
This is what it means to use the right tool for the right job. There is no perfect language that excels at everything. It all depends on what you need to do.
CL can do OO programming too.
What killed Scala at my last employer was that nobody could agree on what idiomatic code should look like, so there were vast stylistic differences between areas. Despite working in the same language, it ended up being hard to move between codebases, in unpredictable ways.
This strikes me as the same sort of flexibility: you can do just about anything. If you do do just about anything, it's a bad time for all concerned.
Common Lisp is one of the few truly multi-paradigm languages. It's annoying the standard has not evolved a bit to bring some ideas you see in Clojure, or some computation models featured in CTM & Mozart/Oz that have made it to Racket. Still, a fantastic language.
The OO patterns are still quite popular in enterprise software, where people mostly work in large teams. Hiding implementation details is terribly annoying for a single developer, but can be a great way to reduce complexity for other team members.
The same consideration applies to other powerful constructs, such as static typing, garbage collection, operator overloading, and macros.
Whether you work alone or in a team can significantly influence how one appreciates such features.
There’s nothing stopping you from hiding implementation details in a functional paradigm, no need for objects or other OO patterns.
I could certainly be wrong, but that doesn't seem to be the case to me.
When you completely separate routines from the data, you end up coupling the code that calls the routine with the data it’s passing. I don’t see how it would be possible to maintain that level of separation while achieving the same level of isolation that’s possible with objects, where it’s possible to truly know nothing about the data in a given interaction.
I’m referring here to the purest aspect, in terms of pure functions. At some point, the data has to come from an impure source, and honestly, I don’t see why a closure would be better than an object—practically, they’re the same thing.
> Maybe because it's easy to decouple data from operations on that data, even if stateful
You can use objects in C++ and Java without mixing code and data (by having data-only and code-only classes for example).
I haven't fully read it, but there's a book from a clojure developer about about this: https://www.manning.com/books/data-oriented-programming
The book itself uses Java, not Clojure.
I know Java programmers use static-method classes, which are just like modules in newer languages. Which just further illustrates the point. It's a hack on top of a language that requires everything to be defined inside of a class. That layer of abstraction on top of things that could be much simpler kills understanding. It massively complicates answering the question "What even is a class?" for a learner. I also realize C++ has simple structs, and classes can be avoided entirely, but that's definitely not the way the language is taught.
Maybe I needed to "git gud", but learning Lisp enabled a career building valuable products currently in production. Java and C# were a roadblock on the way to my current productivity.
I didn't expect that much negativity regarding my comment, I never implied you need to "git gud".
I'm happy in my Clojure job and I would rather not work with OO languages, and that's definitely not how they're taught, but if/when you're forced to use them you can choose not to follow the traditional way and instead write them in a more functional/data oriented way.
I didn't intend a negative tone and that's hard to convey in text.
Sorry for going off-topic, but why is this comment being downvoted?
The comment provides an alternative view on things and even links to a nice book. One may not agree with the perspective, but that's no reason to downvote.
Perhaps it's the user interface (a special upvoting wand would be most welcome for those of us whose fingers are too fat). Or have we reached the stage where script kiddies deploy downvoting bots if they didn't like a comment in another thread?
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
I wish you could use Genera. If you like emacs/slime. You would see how much we lost :(
But here's the thing, and I don't know, I never worked with Genera.
But.
Genera has been gone for over 30 years. At the time, it was certainly revolutionary. But in the computing world, where things move VERY fast, whatever made Genera amazing clearly wasn't amazing enough to replicate in full anywhere else.
I'm not even talking about other languages, trying to get that dynamic environment in modern languages, with modern tooling (which has made enormous strides over the years). But not even in the Lisp world has it resurfaced. Nobody is talking about how amazing Franz Lisp is, or LispWorks, both long running, successful Common Lisp implementations. Run by smart people, run by people "who were there".
We have Slime, with Emacs. We've had Slime forever. We've had solid Common Lisp implementations...forever! People still lament how good the Macintosh Lisp environment was (and honestly, I don't know how, or what made it more than what Slime might offer beyond nice access to the Mac toolbox).
Do you know what has changed in modern Common Lisp implementations since Genera? NOTHING! It's Common Lisp! Common Lisp is 30 years old, and a superset of whatever Lisp Genera was running. And you can't tell me that we don't have modern Genera because Flavors (Genera's object system) is so amazing and CLOS is lacking (because even if it was, it's Common Lisp -- you can FIX IT!, or simply implement Flavors because it's written in LISP!).
There are no secrets here.
Veterans speak of Genera in hushed tones. Sing songs about it. But, however good it was, it's, demonstrably, not good enough to do it again.
Meanwhile, there's been a dedicated pack of folks over at the Pharo side making Smalltalk even more Smalltalk with lots of new development tooling. These are folks that write Pharo so that they can make writing more Pharo even better. I swear, I think they're to the point that they just mount GIT as a file system now over there. I'm not a Smalltalk guy, but, boy, those folks have been riding a rocket for years.
So, it's not lost. It's abandoned. Left behind. For whatever reason. There's a difference.
What Genera ideas are Emacs/SLIME missing out on that would improve them?
A microcode tweaked down for Lisp. The whole OS being a Lisp image.
Imagine running Common Lisp in bare metal. Like Mezzano OS does, but with your Intel malware ^U CPU firmware designed to run CL at even faster speeds.
YouTube video demoing Genera, among other things:
I've heard stories about that. Sounds awesome.
> 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'.
If you’re working on a project (on its code), then you can (obviously) see its code as well.
Statically typed languages make exploring the code a lot easier, especially with an IDE which leverages the type information to assist in code exploration.
> 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.
This works with debuggers (and is easy with an IDE) in most popular languages.
> 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.
You can do this with most major languages today as well.
I was likely not clear in my explanation.
These three things are all done from the REPL. I don't have any experience doing C or C++ from a REPL.
I disagree that "Statically typed languages make exploring the code a lot easier." I'm not aware of an equivalent in C or C++ to the "esc-." method of going directly to the source.
The keystroke combination to find the definition of a function or symbol using slime and emacs is "esc-." That takes you right to the code. If it is a symbol defined by Lisp, you see the underlying code in the actual source for Lisp.
So the second thing is also done when running a program from the REPL. Once tripped, you can expand each element in the stack to see and inspect the variables local to that function. You can then edit the source for that function, compile only that function in place, then resume execution. I admin that I don't know how to do that in C or C++.
My explanation should have referenced the REPL, which is key to these.
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?
In my case:
- Perl: prototype to C, short things to not spawn awk/sed/sh, or silly things from CPAN
- C: Sadly, C is to computers what English is to science/tech/world: maybe not the fanciest or easiest language, but it's everywhere on low level business and everyone being educated has at least basic competences.
- CL: Crazy things you wont see IRL until 20 years have passed from now.
> On side note, they say that 80% of developers are unhappy, do we think that languages have a big part in this?
Between languages, managers, and processes as sources of unhappiness, I personally would expect languages to come in third.
I think that these practices are almost always tied to languages though. For instance I've never worked at a Java shop that wasn't an overly corporate, manager oriented, scrum/agile mess. Whereas all of the Perl shops have been the extreme opposite. Could be just my experiences, but I see a correlation personally.
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.
>>> There was an essay about Lisp being a "language for smart people"
Boy! Nothing can be further from the truth! At least my experience, trying to teach people to program in java, c, c++, lisp and assembly to both technical and non technical people, the only language that is easy to teach is lisp. By far the only language that everybody “got” and could actually do something on it.
Compare that to c++, where experienced programmers shoot themselves the feet every single day.
I think the essay had less to do with syntax than appreciating what makes lisp special. But sure. I love Lisp's ultra-simple syntax. And it makes macros work, which is indeed a superpower.
> There was an essay about Lisp being a "language for smart people"
Presumably, you are referring to The Bipolar Lisp Programmer[1], an HN classic[2].
No, I was referring to this: https://paulgraham.com/vanlfsp.html
> Lisp being a "language for smart people"
But doesn't autocad have lisp as a language behind the scenes and I would guess that autocad is used by folks who aren't full-time programmers?
Also, I always found a way to use lisp, even when I was CSO. But admittedly these were side projects.
You don't need to be too smart to use it effectively.
I write Go for a living. I run Emacs. I read the first part of the article, thinking about how Lisp used in a personal project makes so much sense because you can build the meta-language to your liking and not make something so weird you confuse your coworkers --
and then I got to the section on Go and I thought wow! This guy really doesn't get it!
>On average, most shops have average people
Yes, hello, that's me! I don't want to figure out some genius's Lisp code. Instead, Go forces the geniuses to write code that I can understand.
>There was an essay about Lisp being a "language for smart people" that captured some of what would give me pause
I think about this a LOT. There is a LOT of this blindness in software philosophical thinking. Just look at FOSS: everyone should be able to view and edit source code. Well that sure made a lot of sense when "everyone" was MIT students because they were Richard Stallman's audience.
But it stops making sense to expect users to inspect source code when users aren't all MIT students. Likewise, use your smart person language on your personal project -- I'm sure it's great. I'll keep using the dumb people language.
And get replaced by an LLM, I guess. But if an LLM can generate Go code (like the author surmises) and not Lisp then it might as well just emit machine code and put us all out of work so I don't know why he thinks Lisp is a moat
I think that the idea that Lisp is for smart people is misguided and wrong.
I don't think a person needs to be a genius to do well in Lisp. As a long-time C and Fortran and Python programmer (and many other languages) it took a long time for me to adjust to the different way of thinking necessitated by Lisp.
Also if Copilot or LLM write Go code, why do we think it can't write Lisp code?
I've dealt with code in many languages that were written by "geniuses" and find that they can be as hard to understand as any Lisp program. Often this depends on the problem being solved. There is a story about Donald Knuth and Edsger Dysktra working on a problem that required no less than four stacks to process. (If memory serves correctly, they found a solution using iteration rather than stacks that was much clearer to understand.)
The solution of Sudoku by Peter Norvig (https://norvig.com/sudoku.html) is a bit of a genius solution but it is written in Python.
It would be a disservice if the article's distinction of smart vs average were to dissuade anyone from learning a new language.
> I think that the idea that Lisp is for smart people is misguided and wrong.
I think it's a misunderstanding. People think that other people are like them (and in particular, think like them).
I think that some languages are a better fit for how some people think. Other languages are a better fit for how other people think. It's not "smart vs. dumb", it's different thinking styles.
Now, if FP (or at least non-procedural) fits your thinking style better, and all you've known is procedural or OO languages, when you run across Lisp it's this amazing, magical experience. You never knew programming could be like this. It's enlightening and freeing. It just fits.
But when you try to tell someone else, and they say, "Eh, Lisp never really clicked for me", you think: "How can it 'not click'? It's this wonderful, magical language!" It's really easy to assume "they're stupid" instead of "they think differently".
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
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.
I play around with quicklisp to develop and tinker.
To test and deploy, I generally use Guix [0] to express a package for my application which pins dependencies to exact versions and optionally can run in a container. I have Guix installed on top of Ubuntu.
This is hobbyist and experimental work so it's not battle-tested.
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.
I didn't give any career advice at all. Why did you think this was it? My career advice would be to keep developing in whatever established and practical language you are using and get paid to use if that's what you want.
Ah, then I accept your advice. I happen to like programming, but I also view it as a practical skill and a means to an end. That's the lens through which I was viewing your post. If your central point was that you personally enjoy Lisp, then I don't have an opinion one way or the other.
I also view it a as practical skill. I'm paid to write in a practical language which is mutating into a monster I no longer consider fun to write in.
But as I started a new project which eventually could be a business, then I can use whatever language I want, as long as it's practical for my use case. Why would I use any other language than one that I already know and like? It would make no sense. If you were to start your project, you would probably pick a language you enjoy using, rather than the one you are paid to use, unless it happens to be the same.
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.
Blog post author here: True. But there's no reason not to write when you are in anger about other languages that you do use every single day. I guess I was just venting and also reaffirming my intention to use CL. I have used it before in a previous job for a quick tool and I know it can be used for more complex stuff, which I have already started building.
I haven't been writing a major piece of software in Lisp for 10 years, so I can't write about that. But I can compare how it feels to write software in other languages vs Common Lisp.
And also, Lisp is a blip compared to Rust or Go right now, so I don't know why it's so terrible to talk about it. People will keep talking about the things they like as much as the things they don't like. And it's fine.
> 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 - "A Reflection of 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.
I should probably write that post, though about "a Lisp", not strictly about Common Lisp. I've been using Clojure to make a living for the last 10 years or so, quite successfully and I can't see anything else that would fit my needs better. I came to Clojure from Common Lisp.
This is a good perspective. I did work in lisp, including production systems (albeit small systems), for many years and authored many open source projects in CL. I'd say the biggest hurdle was the community. There was a strange balance between getting contributors and people going off and rewriting the thing you're working on becuase they can do it better/make it faster/etc. It definitely skews towards people going lone-wolf. A lot of people said this going in but I ignored it because I love the language (still do) but eventually got burned out on trying to do anything real with CL. I absolutely did get highly impactful contributors on some of my projects, and I'm still thankful to them, but there was also some "this isn't fast enough I'm going to just rewrite it" that frustrated me a lot.
One place I think CL absolutely would shine is game dev. I started using it for that a bit and the ability to redefine the system while it's running is an incredible superpower. Forget compile times, rebuilding the state of a game can take a long time and being able to fix a bug or adjust behavior right then and there is really cool. This probably isn't even novel anymore given modern game engines, but at the time I loved it.
That's true of any language or project to be fair. Big egos are everywhere in software development.
I enjoyed using elisp and common lisp for the years that I spent in emacs and stumpwm but it always made me chuckle when I'd read some comment or blog post proclaiming that learning lisp is somehow like ascending to a higher plane of developer consciousness. I feel like that sentiment was really high around the late 00's and early 10's for some reason, but also it may have been because that's when I used it most.
Yes, it is a bit grumpy.
I am in the process of writing an example of
> "Ten Years Building a Major Piece of Software in Lisp"
Coming to a ShowHN soon.
That could be easily be my post a couple of years ago.
Let me give me my post-vitae:
It was great. I had to teach Lisp to a dozen people, convince them it was a good idea. Right now we have many systems ans thousands of lines in code in Lisp. Everybody is loving it. From management, amazed with the speed of development, and fewer bugs, to the test, ci/cd people having much less trouble.
I guess I need to write that then. It's not magic, it's not all powerful etc, but, for me/us, it is better than anything else that is there. Our company library is basically a dsl that grew over decades and it is a pleasure. I work with other tech and it basically really sucks balls compared to CL/SBCL/emacs. I am sorry for anyone who missed out on this, but it is not a religion; use what works for you.
Shinmera recently talked about porting SBCL to the switch: https://reader.tymoon.eu/article/437
Discussed here:
Porting SBCL to the Nintendo Switch - https://news.ycombinator.com/item?id=41530783 - Sept 2024 (81 comments)
OP hasn't even really used Lisp in anger, yet
I've also been dabbling in Go recently, and I'm finding that the culture surrounding it is one of actually understanding what your code does. My main language is Ruby. It hits many of the same high notes that Lisp programmers talk about, and I enjoy writing it. There's just something about the practical, concrete nature of Go code that appeals to me.
Someone once wrote that "Ruby is an acceptable Lisp."
Is Go your first static language? It's not a particularly good one except for certain niches. You might try some others.
I use Go too; I am an old guy and I like C; go reminds me of it. I don't have to remember anything; I can just dev with it without internet if need be. But I can also do that with CL and then, well, everything is better. For me anyway.
I have used CL before, but not in anger.
Try Nyxt and writting an extension for it; for example, some URL rewritter doing what Libredirect does in former Firefox and Chromium browser.
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’m slowly working in something like portacle+multimedia: so you can turn on the computer, emacs starts, an you go doing a little game…
I think deep inside the 8-bit retro people miss that, not the slow-low-resolution computers, but the experience of actually “making” something.
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:
I wish this kind of comparisons actually would look beyond Emacs, into Allegro, LispWorks, Clozure CL.
Yes. I used Clozure CL before and now I use Lem as editor. But I stick to SBCL (at least for now, though I can see myself using CCL again when it supports ARM64). As for LispWorks, I installed the Personal edition and played with it. I can't afford it (actually I can, but I have to find a reason other than tinkering).
> 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.
Honestly, to me that sounds like a red flag. There are already too many temptations to get on a purist mood and spend ages thinking about elegant code structure.
I know, it's ambiguous, "more time thinking than typing" might imply that you spend more time thinking about the core problem you are solving. But let's be real, it's Lisp, you are thinking about how to model your problem elegantly in Lisp, not about how to solve it.
This is incidental complexity, you might feel mightily smart and productive, but you are really not getting anything substantial done. Clean code is critical, but in moderation, you need to constantly prevent it from upstaging the actual problem you are working on.
they clearly haven't tried Haskell!
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.
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.
Practical Common Lisp is also a nice read, and the Cookbook* seems to be coming along quite nicely. There's also CLiki (the Common Lisp wiki), but I'm not sure how up-to-date it is.
This is cool.
Why is this downvoted
Not anymore, I balanced it out
Worrying that Swift is getting worse, now that it's been adopted by Ladybird