I see a lot of posts justifying why Lisp is nice and should be used. These are good. I agree with them. But I would also like to see posts about actual projects written in Lisp.
Compare with Rust and Go. Rust and Go devs write articles evangelizing Rust but that's not all we see. We also see posts about so many useful Rust and Go projects too.
How can we see a similar trend for Lisp? And no, it cannot be writing a Lisp in a Lisp or writing a Lisp in your favorite language or writing your favorite language in a Lisp. I am looking for useful projects that do something useful for users who can't give a damn what language the project is written in.
I searched https://github.com/topics/lisp but a vast majority of the projects there are not software used by actual users in the wild. Most of them are projects that teach how to make a lisp or documentation about lisp. There are some useful software like browser, editor, etc. in there but they are few and far between.
I know Reddit was written in Lisp but it isn't anymore. So that's a bummer.
Does Roomba still run on Lisp? I can't find out with some quick searches.
HN is written in a dialect of Lisp so that is one example. Can we have more such examples? Even better would be open source examples where any college student can contribute?
These kind of comments _always_ pop up and are either terribly missing the point or written in bad faith. There are many in this thread but I'm replying to yours as it is the one with the most replies.
Programming languages aren't just for machines to execute. There are for humans to communicate and collaborate. There are technical concerns of course, but these are secondary to social, economical and aesthetic factors or simply luck.
If you don't get why: They are the equivalent of a bunch of linguists discussing about how good and consistent the grammar of a human language is, compared to, say, English, and then someone chiming in with "well if the grammar of that language is so great, how come only a few thousand people in a small country are using it and there are almost no books published in it?"
> These kind of comments _always_ pop up and are either terribly missing the point or written in bad faith.
As someone who loves coding in Lisp myself I assure you my comment is not written in bad faith. And I am not sure what point I am missing. I read the entire TFA from top to bottom and I liked it!
I genuinely want to see a list of projects (preferably open source) written in Lisp. That would help me to support my other arguments when I talk about Lisp with others who do not use Lisp. Thanks to the HN crowd, we have already received a good list of links and examples in the comments of this thread.
I am not sure why I need to be attacked personally for a genuine question.
you shouldn't be attacked. i think its just that these type of questions do get asked a lot of time just to troll. i personally also think its a bad question because someone can give you a valid answer and you might not find the answer interesting. instead maybe it's better to ask something like:
Q: it looks like Common Lisp doesn't support (software with a C library) but it needs to if I want to do it at work. A: https://github.com/rpav/cl-autowrap
> I am looking for useful projects that do something useful for users who can't give a damn what language the project is written in.
Fair request.
As the instigator of the kons-9 graphics project, I had 2 primary reasons for using CL:
1) It is a language I find enjoyable to develop in. As I say, it is the only computer language I have used which doesn't fight me when I try to get things done.
2) I do hope the users of the system will care that it is written in CL, as I am attempting a language-based 3D system where the real flexibility and potential of the software will be available to those who are willing to develop tools and extensions in CL. More of an IDE and less of a typical GUI-based digital content creation system, of which there are plenty out there.
And a bonus point 3) I wanted to consciously do something different, which accepts the fact that Lisp is not the choice of least resistance. No one ever asks "Why JS?".
> either terribly missing the point or written in bad faith
Honestly, this comes across as a pretty arrogant statement.
I think it is you who is missing the point that many developers would genuinely like to see a cool language being _used_, not just admired or academically discussed. And the parent in no way disparaged the fact that one can very legitimately enjoy a language simply for the beauty of it. But it is still a very valid point to want to see it also being used for useful things.
I know those developers exists, that's why I keep reading such messages in every thread about $dead_lang.
I suggest those developers to stick to sites like https://github.com/trending instead of injecting their popularity contest questions in a thread about homoiconicity and lambda-calculus.
Lisp is pretty much "undead". We all know it and nothing, even investing billions of dollars and man hours to build the best runtime with state of the art GC implementations and library ecosystem will convince the younger generation to use it instead of something like JS. So what's the point of these questions then? Rather than curiosity driven, most of them seem defeatist and a gatekeeping effort by trolls if you read between the lines (and I do agree the post I replied to is not an example of that).
> I suggest those developers to stick to sites like https://github.com/trending instead of injecting their popularity contest questions in a thread about homoiconicity and lambda-calculus.
You are not the sole person who gets to define what this thread is about. The participants together get to decide that, and if you don't like the result, move on, instead of trying to gate-keep.
> We all know it
I'm sorry, what? This is a public forum. You're saying a 20 year-old tech interested uni student who is checking out the site for the first time has precisely the same context and knowledge as someone who's been writing in lisp for the last 30 years?
Your attitude does not bring something positive to the table here.
> You're saying a 20 year-old tech interested uni student who is checking out the site for the first time has precisely the same context and knowledge as someone who's been writing in lisp for the last 30 years?
No, but the trolls do. They know about the state of the language and hijack every Lisp related thread with this question just to troll. These are the majority. You don't happen to read many Lisp HN threads in detail do you?
> You don't happen to read many Lisp HN threads in detail do you?
Again, you could dial down the arrogance.
I do read most threads on lisp in a fair bit of detail, and I don't often find "trolls". I usually find an assortment of people interested in discussing various aspects of lisp, including its real-world utility. And I mostly find the various perspectives to be nothing but positive additions to the debate.
I daresay that you fit the description of a troll much more than someone who dares ask if lisp is actually useful.
I mean, if that's your angle, then I can sort of see your point. But at the same time: if I decided one day to properly learn lisp (so far my interest in it has been as a curious outsider), I would do so not because it's an active language, but because I'm interested in what I can learn from it. Yet I would obviously go and seek out whatever tools are written in lisp, both so I can feel that I'm really using the tooling, and so that I can look into how various real-world projects have been designed using lisp. None of that would make me a troll or a bad-faith actor in these kinds of threads. It simply means I would be asking questions about a topic on which lisp arguably does not excel, but for genuine reasons. Certainly not to rub salt anywhere. And I like to assume the same about other people who ask such questions.
Nice, I like it. Lisp as like the Dracula of languages: immortal and extraordinarily majestic and powerful, but doomed to forever prowl the night, feeding on the innocent--and occasionally turning them.
If anything, your rebuttal is in bad faith. Programming languages are not that dependent on the number of users as human languages are - which are more akin to protocols that both speaker and receiver has to know.
What reason is there to prevent someone who learnt this language to utilize it to “communicate with their computer” and share it with the rest of us? And I say that as someone who do like Clojure for example very much.
My opinion/answer is that while lisps have plenty of properties that make them great and that one gets used to all the parentheses, we as humans in the end are simply find it more alien then other languages, too uniform of a syntax hinders human parseability. (That’s why I think that clojure made a very great and pragmatic choice by introducing some other primitive data structures).
> Programming languages are not that dependent on the number of users as human languages are.
But it's still a significant factor. CTOs base their technology choices (languages and libraries) on the popularity of those.
Common Lisp is one of my favourite languages, yet when programming something with my friends I have to do so in other languages. Why? They simply don't like the syntax. It looks weird and alien to them. No amount of ecosystem, usability and performance improvements will make them ever consider it, and that's fine.
> Programming languages aren't just for machines to execute. There are for humans to communicate and collaborate. There are technical concerns of course, but these are secondary to social, economical and aesthetic factors or simply luck.
You're missing the whole point. These non-technical aspects rear their heads in real-world projects, and perhaps are more critical than technical ones. If a language is subpart in its non-technical aspects, developers are very quick to replace them with languages that are better.
And as the OP pointed out, Lisp is rarely seen or showcased in real-world projects.
Therefore someone asking "if Lisp is so great, why doesn't it get any real world use" in such a thread is doing so in bad faith.
Did UNIX win because it was the best OS at the time? What about VHS? You're oblivious if you think technical merits matter whenever you have to deal with economic factors and humans loaded with biases.
> Programming languages aren't just for machines to execute. There are for humans to communicate and collaborate.
"All it does is segfault!" I wake up in a cold sweat. It's still dark; a quick glance at the clock shows that it's about 3 in the morning. There's a stir besides me.
"Was it the dream again?" My wife says from the darkness to my side.
"It's fine, just go back to sleep."
She mumbles something incoherent and in a few moments she's snoring quietly. I lie down, but I already know there's no more sleep for me tonight.
+++
In the morning I arrive late in the office. I was in the parking lot at 7:30, but it took me an hour and a half to work up the nerve to walk in the building. They're at it again. The "collaborators". After we invented the perfect programming language for human communication and collaboration (we-lang) software developers took to calling themselves 'collaborators'. Today they're rehashing the same argument that they've been on for the past month.
"Michael, why are you always late? The computer is doing it again, and you know you're the only one who gets it." A loose mob of collaborators are standing around a 50 inch monitor on the wall. A half blank terminal monopolizes the screen. It seems to have been in the middle of producing log output, but now the cursor blinks lazily at a final message: "generic fault encountered".
It started with looks of confusion, then contempt, and finally resignation. And now I stare back, knowing how today is going to go. The same way as all days. "Yes, there are two problems, which is what I was trying to say yesterday. The first problem is that we're launching multiple threads and then they're all trying to modify the same unlocked data. And the second," I take a deep breath, "and the second is that the goal is kind of an open problem. We're potentially ambiguous in a few places and even if we weren't then it could take decades for the fastest computers to brute force a solution that conforms to the spec."
"Michael, we've been over this before. We all agreed that this is the nature that the UI should follow. We all agreed that this is how the back end ought to work. Why can't you, those mathematicians you keep talking about, and the computer all just get with the program. Maybe try being a team player for once." In the mob heads nod in ascent. We-Lang is perfect. Everyone agrees and understands everyone else. The collaboration between humanity has been achieved as if we were a single person. One mind. Unification.
But when we run it on the computer, all it does is segfault.
Lisp was Python in the first AI wave, and having it failing to meet expectations burned many bridges.
Commercial software + hardware required to comfortably run Lisp Machines was more expensive than UNIX workstations.
Having paid for UNIX workstations, most shops would just use C and C++ instead of paying for commercial Lisp packages on top, plus scripting languages like Tcl and Perl brought a bit of Lisp like experience into UNIX.
Eventually most of the stuff that made Lisp awesome ended up in Smalltalk, Java. .NET, Dylan, Julia, Python however there is still plenty missing from the whole experience.
The whole Clojure ecosystem is another worth considering, including systems like Datomic, and Datomic Cloud (commercial product and SaaS product respectively).
Before this list, people said "Sure CL is used in production, there's Google and uh… Autocad". Now, we collect companies that we hear about. Nothing "official" nor exhaustive, of course. You can still complain, but not for the same reason ;)
>If you have so few that you can maintain a list, it kinda proves OP's point
OP didn't really make a point. He just said that he would like posts about lisp being used in production
> Also as an addendum to his point, what about projects being written in the last decade or two?
It's a niche language so it's pretty pointless throwing lists of all CL projects in production at people. Instead I suggest you say what domain interests you and maybe someone who worked in your domain will be able to give a more meaningful response
> Emacs is cool, but it was created in 1976...
Wow I forget how old my operating system is given how "modern" it feels and that to this day nothing even comes close to it
> OP didn't really make a point. He just said that he would like posts about lisp being used in production
+1. I am the OP that asked the question. I wasn't making a point. I was asking a question. The company list provided in the response to that was helpful.
> It didn't end in 1976, though.. it's creation continues to this day.
Legacy projects tend to reflect the state of the art of the time they started, which reflects on aspects such as software architecture, technologies, and more importantly the overall technical commitment and technical debt which makes it hard or practically impossible to fix past wrongs or replace subpar technologies with better options.
Emacs started out in a time when Lisp was the only game in town in terms of dynamic interpreted languages. That's perfectly fine. Would the same people stick with Lisp in a time when, say, the likes of Python and JavaScript and Node.js and Ruby and .NET exist?
Also, the Emacs that we know and use today (GNU Emacs) which is actually based on Lisp, started from a decade later (1985). The 1976 Emacs was written as a series of macros for the TECO editor (hence the name Emacs for editor macros).
Every programming language doesn't have to be trendy on GitHub with a bazillion projects.
Lisp was a major programming language as it powered nearly all AI research for many many years and many of it's ideas have spread into languages we use today. For instance, it was the first language with a garbage collector !
It has many more or less direct descendents that are used
The fact it was created some 70 years ago, but still run nearly unchanged and has active users and project is an achievement.
> "Used today in production" does not mean that it's not dead.
I guess you need to define "dead".
I have to agree with others here that Lisp is not dead for the simple reason that Emacs is not dead. Emacs has a thriving community of developers who code and use Lisp almost everyday to solve problems.
Org-mode alone has a large number of users from all walks of life, from writers to event organizers and Lisp code is written for Org-mode everyday.
There are high-profile well known companies that use Clojure for processing high volume of transactions. They are in all probability writing Clojure code everyday that is going to production everyday.
What exactly is your definition of "dead"?
P.S. You have also completely misrepresented my earlier comment in your comment here - https://news.ycombinator.com/item?id=33464215 so I am not entirely sure if you are arguing here in good faith or if you have an axe to grind.
Not the parent poster, but I would define "dead" as "not being used for starting new projects with intent for these projects to be used in practice".
If a language is being widely used in specific existing 'legacy' projects and for people learning it to get a job in their maintenance (e.g. COBOL?), then I'd say it's dead. If during the last five years every organization considering what language to use for their new production system (as opposed to someone's toy project or learning project) chose something else, then that language apparently has no valid niche remaining and is effectively dead, being chosen only due to legacy/compatibility reasons if the system was already started with it.
As the parent poster said - PHP4 sites exist in production and people work on PHP4 code maintaining them, and PHP4 is undeniably dead despite all that.
Also, I'm not sure whether I'd equate Clojure with Lisp - I'd treat it as a separate language/ecosystem evolved from Lisp as it was commonly understood; I'd consider Clojure activity as evidence that "Lisp may be dead but its descendents live on".
In 2015, Paris Airport Air Traffic Software were running on windows 3.1.
Is windows 3.1 outdated ? Yes. No longer a public facing product ? Yes.
Dead ? Absolutely not (at least back then, maybe it got decommissioned).
Around that time, a friend of mine was doing his master Thesis in an astronomy lab. He had to load fortran 77 routines from a 5" floppy disk that were doing critical computation (they were in the process of migrating). Same diagnosis: outdated, became a niche product, but not dead at all.
IMHO the Lisp community is a bit more closed than those of other programming languages. They have their own pages and blogs presenting projects. Anyway, for commercial, proprietary usage, there is the following list of companies:
I am not a professional coder, just an amateur. Following the example of LISP, and even lambda-calculus, I was able to build a text editor with a programming language, working on any web browser: http://lambdaway.free.fr/lambdawalks/ , that I use daily to compose quite complex documents containing code evaluated in realtime. I would not have even thought of undertaking such an exercise without the existence of LISP.
Speaking of text editors, I think one thing that hampers adoption of lisps is being a bit more beginner unfriendly, at least for most implementations. The developing environment is trickier to set up, and a common recommendation I often hear is to learn Emacs first, what is quite a upfront investment, while in, say, python, you can just launch IDLE and start working in a basic, but proper environment right away.
> I think one thing that hampers adoption of lisps is being a bit more beginner unfriendly
I realize you're talking mainly (exclusively?) about the editor situation, with which I don't disagree; but aside from that, I feel like learning Lisp as my first language sort of brain-damaged me for learning other languages, even ones thought to be simple to get started with like js or Python. The Lisp syntax and programming model are so simple to wrap your mind around that everything else, to me at the time anyway, looked noisy and inconsistent. Then I discovered Tcl and Prolog, found them as easy as Lisp to work with, and discovered I just have a super low tolerance for syntactic complexity.
> I am looking for useful projects that do something useful for users who can't give a damn what language the project is written in.
the note taking app I use is a fairly popular clojurescript project, first thing that came to mind. https://github.com/logseq/logseq
In general Clojure is pretty popular in particular on the backend. Nubank is I think primarily using Clojure, but Walmart, Atlassian and a bunch of other big companies do to.
Do you feel that fennel was merely a slightly nicer way of writing neovim plugins, or did it in fact give you a significant boost in productivity/capabilities?
Difficult to say, as I did not measure anything. From the code I've written I get the "feeling" that it is more compact compared to plain lua, reducing (my) cognitive load.
Fennel transpiles to lua, it doesn't give more capabilities, I would say. The concept of productivity (and capability) is anyway confounded by so many factors, making the choice of programming language negligible (unless you pick one of the extremes, such as Brainfuck, of course).
They certainly are! I use both everyday. Emacs and Org-mode are so ingrained into my brain and fingers that I just totally forgot that I am using a Lisp system everyday while posting my previous comment.
It's an algorithm which understands momentum in the stock market, and finds where that momentum is flowing to find stocks with a good chance of really high gains. It averaged 9.17% daily increase across 127 stocks last month[0].
Lisp was a conscious decision because it allows a small team to be incredibly productive, plus the fact that it's a live image allows you to connect to it over the internet and poke and prod the current state, which has really allowed a much clearer understanding of the data.
I've also written or contributed to several projects and products written Common Lisp, Scheme, Clojure, and (back when it was a Lisp) Dylan. These include, but are not limited to the following. Some of these are projects or products that I created entirely on my own; some are collaborations, or projects to which I contributed.
Some of these were years ago. Some of them are still on the market or under development.
- Panels: a constraint-based programming-by demonstration system
- GATE: a knowledge-based machine-control and compatibility-testing system used at Apple
- bauhaus: an operating system for mobile devices
- SK8: a rapid-application-development system
- The documentation toolchain for a startup's network-security product, later acquired by Cisco
- Clozure Common Lisp: A free and open-source Common Lisp compiler and development system
- Alpaca: a WYSIWYG word processor with Emacs-like customization features
- A syntax-aware diffing tool created under contract
- A rules engine for a set of educational games for the Office of Naval Research
- The entire control and UI stack for a forensic fingerprint livescanning product
- Delectus: A list manager for end users on macOS
- Categories: a loadable language-agnostic object system with configurable data model and dispatching
- The Fabric: a prototype immersive 3D networked multiplayer game
- clio: a work-in-progress cross-platform GUI framework
- OddBabble: a prototype of a knowledge-based social network
If you don't see a project in your field it doesn't mean there is no software or library.
Are they as awesome as the Rust/Go projects? It depends.
Is it an exhaustive list? No.
For a list of companies using CL and more projects, old or current, see the other links.
## Music
- [OpusModus](http://opusmodus.com/) - a comprehensive computer-aided environment for the whole work of music composition. [Proprietary].
- [OM7](https://github.com/openmusic-project/om7) - a new implementation of the OpenMusic visual programming and computer-aided composition environment including a number of improvements on graphical interface, computational mode, and connection to external software libraries. [GPL3][2].
- [ScoreCloud](https://scorecloud.com/) - A web and mobile application to automatically create music notation from music performance or recordings. Built with LispWorks.
## DB tools
- [Pgloader](https://github.com/dimitri/pgloader/) - Migrate to PostgreSQL in a single command!. [PostgreSQL License]
- [Pgchart](https://github.com/dimitri/pgcharts) - A self-contained web application that takes as input an SQL query text and outputs its data as a chart. [No License Specified]
## Utils
- [Cepl](https://github.com/cbaggers/cepl) - Code Evaluate Play Loop. [2-clause BSD].
- [Regex-coach](http://weitz.de/regex-coach/) - a graphical application for Windows which can be used to experiment with (Perl-compatible) regular expressions interactively. Freeware.
## Text editors
- [Lem](https://github.com/cxxxr/lem) - Common Lisp editor/IDE with high expansibility. [MIT]. Works for many languages, has a LSP client.
- [Sketch](https://github.com/vydd/sketch) -A Common Lisp framework for the creation of electronic art, visual design, game prototyping, game making, computer graphics, exploration of human-computer interaction, and more.
> But I would also like to see posts about actual projects written in Lisp?
What would you like; an example of Lisp being used in a particular domain; a how to guide? You can use lisp for everything you can build with C/C++/Python/JavaScript
Do you want to learn Lisp so you can get a better paying job? I don't think any lisper wold recommend that (unless you want to include Clojure + JVM in that equation). Lisp simply is not that popular
Do you want to learn Lisp so you can master computing? Great idea!
Do you want to learn Lisp so you can prototype a truly novel idea for which you cannot find a plugin library? Great idea! The examples of Reddit and Roomba you gave are exactly this.
I really wanted to get Lisp. I thought, I can't get onto the pedantic train of Haskell, but maybe I can do for Lisp. Had a play with Common Lisp and Scheme and... Nothing.
It's not that I found either to be bad. I quite like the syntax actually. There were some nice things too, I get how macros are neat.
But I didn't get that cathartic realignment of magnetic domains. I saw a neat programming language. In fact (gasp) I couldn't see many massive wins over my go-to Python.
- yes, lisps are compiled and to some extent statically typed, so that's one
- I get the REPL programming experience is better, though somehow it didn't hook me.
- Macros... Yes Python doesn't have them, but there's so much introspection that in practice, whenever I saw a macro example, it was clear how to achieve the same thing with Python.
I didn't get that deep into it, but every time I was presented with a Eureka moment, it was a bit underwhelming.
I can't quite reconcile the promise/hype with my experiebce. Maybe i didn't give it enough time, but then how much is enough?
I think a lot of the evangelism happened before Python and other languages both picked up steam and integrated some of the powerful ideas, e.g first class functions / closures or a powerful object system, so the chasm is now much narrower.
I’ve read a few pieces by prominent lispers who moved on to Python for similar reasons, along with wider adoption with a bigger ecosystem.
So you’re not wrong in thinking that. But I do believe there are a few things beyond macros that Lisp makes fantastically trivial that wouldn’t be so in other languages. It just doesn’t seem as magical anymore since we’ve raised the baseline for what is possible, for what to expect from a language. That is due in part to the influence of Lisp itself - lambda the ultimate own goal.
I played around with Guile scheme for awhile. Also a bit of Perl. I wanted to write a simple utility, and chose Python. I am familiar with Python, but hadn't used it for some time. Getting back into it again, my conclusion was: Python, it Just Works.
For anyone interested in lisp I suggest guile. Especially if speed is important. Guile can be interpreted, but it becomes much faster when compiled. The beauty of it is one can mix and match compiled code with interpreted code in the same script/program (usually this is done to run the interpreted code in another security context, allowing it to only do some "stuff" - this is especially useful for software deployments etc) - they call this feature gexp. Of course all this can be done with python too, but IMO such things are ugly/convoluted/complex in python while in guile they are very simple /straightforward).
It is basically a lisp language, but with a "curated" set of standard libraries that do a lot of the stuff one may commonly need in a predictable way.
Documentation is definitely not ideal, but it exists and there is a lot of it. Often one has to look through already written code to figure stuff out, but there is lots of that code in for example guix.
In summary, would I suggest anyone uses guile(or lisp in general) for a commercial project instead of python? In 99% of cases the answer is "definitely no", but does this diminish benefits of learning it? No, too. IMO one almost always benefits from learning new languages as long as the new language introduces new concepts. One gains a wider perspective and who knows, perhaps one day, one is involved in scoping that 1% of commercially written software where one may think, yes guile is the way to go.
>That's a standard feature of many Lisp implementations since the dawn of time.
Yes, of course. I mean this from the point of view of someone who doesn't know any other lisp. Not as an advantage of "guile over lisp" . Guile is a lisp after all.
> I couldn't see many massive wins over my go-to Python.
A massive win over Python I get is performance! The performance of SBCL or another good implementation beats Python hands down. And I don't have to lose anything to gain that performance. The syntax is much cleaner and more enjoyable than Python. Quicklisp provides a wide variety of packages that I can use to build software. So it has the advantages of Python and superior performance.
Performance is of course very good for SBCL. I guess 90% of the time it's not a constraint for me, the rest of the time maybe yes.
On a broader "performance" side though, the executables are enormous. If I'm tinkering with a new language on the side, I like to build little utilities - like, say, transposing a csv file. Having a 60MB executable for doing it seems... weird. Can't quite put my finger on it.
Of course, if I were to "compile" Python that way, it wouldn't be much smaller.
Yep that’s it, the code is data, data is code thing, which makes it trivial to write Lisp programs that produce Lisp programs (that in turn produce Lisp programs). Macros all the way down, and at the bottom a couple of elephants.
I suppose the "Eureka" moments were more impressive when Lisp started getting adopted (when the alternatives were to manage your own memory and even routines were not an object).
But it still has better compactness than Python, in my comparison full of caveats.
The compactness is more to be expected in mid- to large-size software. Where one uses macros to develop internal domain specific languages, etc. Long ago I was at a talk where a project manager reported that their slightly over 100 people Lisp team could compete with a roughly 1000 people C++ team, both developing a similar product (an enterprise network switch).
funny, every time i see a pycon talk about metaprogramming, i can only think "nothing that CLOS couldn't do since forever" :)
as other said, python got a lot from lisp so of course it looks underwhelming
but the lisp history and culture is still worth a lot (and there's more to mainstream lisp than is usually shown, people did context oriented programming prototypes, aop, interface passing ideas. As always lisp evolves)
The ability to do interactive development in Common Lisp is something you won't find in basically any language. Smalltalk and Forth are probably the only other languages that have similar capabilities (modern Smalltalk images still have zombie processes and unreachable data from decades ago before the implementations had proper garbage collection).
Python REPL can't compare to what CL offers. In CL, I load up a bunch of files and start coding with my codebase running in a REPL. Whenever I make code changes, I can patch in those changes to the running instance. I can try them out instantly. If I've accidentally caused complex conflicts with running code, CL has the tools to deal with them. You can even do this kind of interactive updating against running CL instances (more importantly, you can do interactive debugging against production instances).
In Python, you can have a repl open, but there's not a good way to monkey patch everything. Loading all the things is painful. Stuff like adding new libraries to the repo can cause conflicts. If you update just one definition in a file, you must reload everything which makes those complex conflicts more likely, but Python also doesn't have the tools to solve those conflicts. You aren't getting anything interactive unless you are explicitly running your app in a debugger (and doing this in production just isn't going to happen).
Another fun thing about Common Lisp is dynamic bindings for some things. It's not strictly necessary, but makes certain things a lot easier where you can configure a variable that updates the variable in the called function(s) rather than having to pass it in every time you call those function(s).
Finally, on the macro front, macros are compile time while your Python equivalents are runtime. This is a huge difference when it comes to performance. Python is already dog slow and doing a bunch of dynamic stuff makes that even worse.
While Common Lisp is my favourite programming language, I didn’t necessarily get the Eureka moment by just programming in it (although I understood quite early how the interactive REPL driven way of programming is superior to any other form of programming) but instead when I started to learn more about lambda calculus. Then it really clicked for me.
The Eureka moment for me was when I realized that I can express LET in terms of LAMBDA. And why stop there? I can express DEFUN in terms of LAMBDA too. All of the code is just LAMBDAs and LAMBDAs. That's when it really clicked for me!
When I discovered that I could forget the cons, car, cdr of LISP and rebuild them from the ground, the lambda-calculus, a very basic "text rewriting" tool, the Swiss knife of the code, the TAO of code ...
I also dabbled and didn't have an overwhelming Eureka moment. I do firmly believe there is one to be had though. I suspect it comes when you discover that you can bend the language to your will to solve problems in ways you couldn't have imagined, or would be very difficult in other languages. Lisp is isn't just a program language, it's a programming language toolkit more than most.
The reason why I don't pursue it further is that as a language toolkit, each project evolves effectively into its own language with less portable knowledge if you were to work on a different project with a different team. [For that reason and I do like static types.] Lisp might be more comparable to Perl "there's more than one way to do it". If I were to pursue lisp, I might choose Clojure which has more 'batteries included' and an ecosystem that makes different projects perhaps share more.
I haven't been doing Lisp in a looong time. But in other languages, I do find it annoying that my own code has to abide by certain rules that the implementers of the language do not have.
For example, most languages have "if" statements, but I can't define my own "unless" statement. I have to make do with "if not". In Lisp, it's pretty trivial to make an "unless" that works just like "if" does (except for the negation, of course).
In practice, I'm working on a pretty large Java code base right now, and if I have the need to pass around a value that is evaluated "later", then I have to pass around a lambda expression, and the syntax makes it very clear that there is a lambda expression here. For example, if I want to pass a boolean and a number and I want to make sure that the number isn't computed unless the boolean is true, then I have to write, in Java:
someMethod(b, () -> a + 5);
Here, "b" would be the boolean, and "() -> a + 5" is the lambda expression that allows "someMethod" to avoid evaluating it in the first place.
In Lisp, I can pass a lambda, too:
(someFunction b (lambda () (+ a 5))
But I can also define a macro, so that I can call it like this:
(someMacro b (+ a 5))
Much less ceremony. It does, of course, however, require that you know that this is a macro and that it has special evaluation rules. If you need someFunction/someMacro often in your code base, then it makes sense to go for the macro, and your fellow devs will learn how it works. But if there are just one or two spots in the code base, it might be better to go with someFunc and the lambda because then it will be obvious how it works.
I've basically resigned myself to passing around lambdas all over the place, but it doesn't make me happy.
I would say, keep writing things with it on the side. Maybe it will click like it does for many. For me syntax in other languages is noisy and annoying, but I cannot write lisp full time. I am building my own (as you do) just to be able to code some outside my regular work.
Also; I would forget about macros generally. In my opinion they should be used in very rare cases where other solutions are not pretty enough or really do not work for the usecase and these are rare in my experience.
also the state of the art got slowly most of lisp features.. Nowadays it is not rare anymore metaprogramming in the form of macros, introspection or compiler extensions.
With lisp is still trivial to make a metacircular editor and bootstrap another language, also to create DSLs, but the industry is not appreciating such things anymore as standarization and tool homogeinity seems to be nowadys much better valued.
I can see why someone would learn Lisp as learning a different paradigm than what you are currently using helps you see thing in different ways and improves your overall ability to solve problems.
What I miss is what classes of problems Lisp helps you to solve better and faster. Why use Lisp in production?
If you want functional programming there's ML, F#, Haskell and even Javascript. If you want to develop fast, there's Go, C#, Python and so on.
I am not trying to denigrate Lisp here or to say something is better, I am genuinely asking what advantages Lisp has, what are the cases for which is it best suited in production.
There are no other homoiconic languages with amazing REPL support.
After writing Lisp there is just something wrong about how most languages have an additional step in order to generate the AST. Why? A tree is a simple structure and describes the shape of code well. I can just write it myself. There is no reason to add weird arbitrary requirements on how you have to present your source code text to the compiler -- just feed it the data structure representing it instead.
Since your code is just a tree now you can also write macros that are just functions. No text substitution or preprocessor jank. This is an amazing simplification and just feels as if it is the way it should be.
Touché. Excuse my ignorance, feel free to correct me, but I've always viewed Prolog as suited to specific tasks, whereas Lisps are more general purpose. There's games in Lisp for example, not a lot, not all of them great, but they're still there. I'm not aware of any Prolog games.
SBCL is also within 2x-4x of C quite a lot so unless you really need every last bit of performance you're fine, as opposed to Prolog's snail-like tendencies. Static typing and turning off safety checks/turning on optimizations can get you very close to as fast as you'll ever need.
Prolog is probably less of a general-purpose language, in the sense that writing things such as games are probably not a very suitable goal for it.
But for any problem involving the exploration of a solution space, prolog is absolutely stellar and actually quite fast, and even faster to write: solvers, irregular data processing, symbolic reasoning... It also lends itself quite well to "I just want to query a database" apps, including websites. Have a look at the "power of prolog" YouTube channel if you are interested.
You underestimate the cognitive burden of resolving syntactic ambiguity with non-lisp languages. So many problems disappear with s-expressions that when I return to a language with a "human" syntax I feel bad that I have to work harder.
Possibly, but I would argue we're not doing a very good job at that. Things like precedent rules plug into what we're used to for mathematical expressions, but that's only a small part of actual programming. Teaching novices without prior PL experience, you notice how much language syntax can get in the way, I get to the core concepts faster with scheme-driven classes than python-driven ones.
Question to HN: have there been recent interesting empirical studies into the impact of PL syntax? I tend to always cite https://dl.acm.org/doi/10.1145/2534973 but newer ones might have superseded it.
> Because it's possible to have a lot better representations of computer code for humans than AST.
Which are those? I assure you I am a human and I find s-expressions to be clean, elegant, easy to read and easy to understand. I have learnt C, Java, C#, PHP, Perl, Ruby, Python, Go, Javascript, C++, Rust over the years and I have not found a syntax that feels better to me, the human.
When I am writing tools for myself I reach out for Lisp because it is the most convenient one to write code in. I don't have to worry about all the syntactic ambiguities and complexities of these other languages. With Lisp, I can focus on solving my problem without being weighed down by complex syntaxes of other languages.
You are saying there are better syntaxes out there? Where can I find this elusive language which has better representations of computer code for humans?
A lot of this is pure preference, and if we try to debate the merits of prefix vs infix operators we're just going to yell MY PREFERENCES ARE RIGHT AND YOURS AREN'T at each other until we get bored.
But there are some places where I think Lisp syntax is objectively worse than the alternatives. Parsing Lisp is easy because it shifts all the hard parts to the semantic layer. Everything looks so similar that you have to do a lot more reading, and memorization, to know what's going on at all.
----
To take a supposedly good example from elsewhere in this thread[0]:
> (do-a-thing b (+ a 5))
Is this a function call, or a thing that expands into something totally different? It matters, because (+ a 5) may not be something so trivial - it may have side effects, or be evalulated multiple times. (If it was a lazily evaluated pure function, there would arguably be no point to having macros at all.)
This one is trivially solvable by making macros visually distinct in some way, e.g. Rust's ! suffix, or C's convention of MACROS_YELLING_AT_YOU. It doesn't matter what the syntax is, as long as it exists.
----
Is (progn a b c) a function call or a special form? What about (proxy a b c) or (pregen a b c), both totally plausible names for functions? It's totally possible, even easy, to tell those things apart if you're paying attention, but you have to actually read the word at the start and comprehend it. In languages with dedicated syntax for this, you can just recognize { and } and instantly know what's going on, no need to involve the word-recognition parts of your brain at all. This sounds trivial - nearly all syntax decisions are - but it adds up when everything in the language is like this.
----
[0] https://news.ycombinator.com/item?id=33469932; I've renamed the macro here to make my point clearer, because the obvious response would be "well obviously someMacro is a macro", but in the real world people do not name their macros that.
lets me look up standard language things by pressing L while the cursor is on a symbol like progn; it launches a browser window on the doc, and jumps to the section. For stuff that is in the code tree being worked on, there is jump to definition via tags.
> In languages with dedicated syntax for this, you can just recognize { and } and instantly know what's going on, ...
If you don't already know the construct, it may be hard to search for it, especially online.
Recently I wanted to see some examples of C++ lambdas in code bases. I tried searching for things like "[](" and "[]{" and whatnot on github; no luck.
> C's convention of MACROS_YELLING_AT_YOU.
Plenty of C macros (that do non-obvious evaluation) get written in lower case.
Even if you think you're sure something is a function call, that tells you little. You might know that it won't clobber the argument expression, but what you often need to know is what the construct does; and in the course of finding that out, you will find out whether it happens to be a macro.
I wrote a response saying what I do to counter these problems.. but actually, I think introducing some form of syntax to differentiate macros would be amazing. I wonder if macro symbols could be pulled automatically from packages and suffixed with ! if they are not so already. A new symbol could be added to the package so as not to internally affect the code. Thanks for the idea.
While .NET and Java are the platforms that come closest to the dynamism of Lisp based environments, their code reloading is still not as flexible as on Lisp environments, specially Common Lisp.
Also they are still catching up on the expressiveness of CLOS.
Or the ability to code like in StarLisp, where the same Lisp code could run locally in a compute node, being distributed across the network, or some kind of compute accelarator (we are still dealing with plain old C and C++ alongside language extensions). Chapel and Julia are probably the closest to this experience currently.
Finally very few tools combine the workflow of having a JIT based REPL, with the dynamism of Lisp for interactive development, while being able to AOT compile everything for a release delivery.
I've been hearing similar arguments from lisp advocates for decades but lisp is still a tiny niche in the programming world. Is this because programmers are just slow to catch on to superior technology or because infinite malleability is not that helpful in actually building shipping software?
A lot of important ideas originated in the lisp world that are now mainstream like garbage collection, functions as values etc. But I think there are good reasons that most of us don't use s-expression syntax at work.
> infinite malleability is not that helpful in actually building shipping software
Infinite malleability is bad in a team, great alone. I have projects in Common Lisp that are backing more traditional websites (contact form backend with a lot of integration and customization built in, google sheets, email etc.). No one's ever seen the code. No one even knows it runs Lisp. But it's there and working, for years on end, and it takes me very little time to make any occasional changes.
That said, it's a lot of custom code and syntax I built, so somebody new would have to learn it if they collaborated with me. And they would obviously have to know Common Lisp in the first place.
Lisp is great for hacking alone, but I think a company might be more efficient just hiring a couple mediocre Java devs and calling it a day.
> lisp is still a tiny niche in the programming world
You could look at this the other way and be impressed how much Lisps are still used despite being many decades old and all the pressures from other languages.
> Is this because programmers are just slow to catch on to superior technology or because infinite malleability is not that helpful in actually building shipping software?
I think a lot of it is momentum / fashion / network effect or whatever you want to call it. I've done some work with Lisp in the past and loved it, but I struggle to justify spending time on it.
From a corporate level, if you decide to go with Lisp, then you are significantly limiting the pool of available engineers and libraries etc. you can choose from. Whereas if you go with Python then you get a language that is a bit less elegant but close enough in flexibility most of the time, plus a vast ecosystem of resources and expertise to draw from.
On a personal level it's similar; Lisp isn't exactly a drawback on your CV, but there's an opportunity cost. There's usually something else to prioritise that will make you more attractive.
Citizen Kane and Akira Kurosawa movies get put high up on the list of the best movies of all time. If someone is on a 10 hour bus ride, they aren't going to watch these, they're going to watch the latest marvel movie or star wars series.
Lisp may be the most influential programming language of all time, but that doesn't mean it's the best tool. It has a fragmented old eco system, it isn't as simple as scripting languages, it isn't as fast as native languages and its main advantages have been built in to other languages a long time ago.
in general good does not equal popular. and i think its useless wishing that lisp is popular. if it happends so be it. but for "some" reason it keeps on living and people keep building important things with it
Thanks. Malleability and redefining classes in running code sound like advantages. Can you point to a situation where you might want to redefine classes in live code?
In a game engine, you don't want to rebuild everything just to change a couple of details in the scene. Live++ and VC++ reload are quite far from what Lisp allows.
Somehow it is seen valuable enough that Erlang, Java and .NET developers enjoy similar tooling in production, just not with the same depth as Lisp and Smalltalk.
> Why use Lisp in production? If you want functional programming there's ML(...)
Maybe this language has a bad name but I can not find anything about it on HN.
> what are the cases for which is it best suited in production.
I'm not a professional programmer, but one of the best things about Common Lisp is that you can find code that was written decades ago and it still works without any changes. You may say that longevity is just a coincidence, but I believe that this is one of the proofs of the enormous power of this way of writing code.
I would like to have a PC/Smartphone without having to change devices for the rest of my life (not expected to see that much progress in hardware anyway) and be able to install any old or new app. What a pity that the industry has chosen the method of planned obsolescence in both hardware and software.
They always end up being hacks in Python and are almost impossible everywhere else. Numpy, various ORMs and so on.
Since you get a built-in de-facto compiler (macro expander), implementation of such DSLs is pretty easy. Racket, for example, has pretty good support for pattern matching and error reporting during macro expansion, which makes the DSLs debuggable.
Typed Racket has implemented a type-checked layer on top of the regular Racket with automatic unboxing of numeric types whenever they provably don't have to be boxed. You can mix typed and untyped code freely with contracts being inserted at the boundary. That means you can implement a busy loop in typed code with unboxed integers and only guard the inputs and outputs. The potential clearly is there.
As a Lisp/Clojure beginner, I don’t find s-expressions any harder to read – in fact, I like how much they take away the cognitive load associated with remembering and applying syntax rules in other languages.
But for me there is one exception that often hecks me up: comparative operators `<`, `>`, etc.
It might be due to the conditioning of infix notation in math education, but when I write `(< x y)` or `(> x y)` I somehow often manage to get the order confused, while this never happens with `x < y` or `x > y`.
I wonder if other Lisp programmers experience the same issue. This is my first year programming exclusively in Clojure, so maybe I just need more time to get used to it.
I don't have the same experience. I find s-expressions more pleasant to read. On the other hand, I find the syntax of C, Python, etc. to be jarring! The syntax of Rust and C++ feels like nails on chalkboard to me. What I find even more uncomfortable about C++ and Rust (and Python to some extent) is that they keep innovating on syntax and the syntax becomes more and more complex as years go by.
Compared to that mess, Lisp's s-expression is a breath of fresh air. The brain ignores the parentheses soon (just as the brain ignores the braces in C-like languages) and relies on the indentation to understand the structure of the code.
Having said that I do find the prefix notation slightly unintuitive for complex math formulas. Simple stuff like (< x y) is clear to me. No confusion there. But something like the formula for finding quadratic roots feels a bit unwieldy in s-expression syntax. I am sure that is because of years of conditioning of infix notation. Because pre-fix (or post-fix) are purer and unambiguous representations of the mathematical operations we perform. Yet conditioning has made pre-fix or post-fix hard to read for complex math formulas.
If it helps, I always imagine a little guy skiing down the top of the sign, > he has to ski to the right, < he has to ski to the left. That's the direction the arguments are going highest to lowest.
Maybe my problem was that when I write `(< a b)` I unconsciously read `< a`, which is where the confusion begins when I don’t explicitly think about the order. But the skiing guy helps to make it clear und easy to imagine what is going on (especially when I keep in mind that the operator is variadic in Clojure) and hopefully this will replace my “autocomplete error” in the long run.
I found that a lot easier to deal with if you embrace the added arity of the comparisons. Specifically, I don't read (< x y) as "x less than y", rather, I read it as "increasing x to y." This can work with (< x y z) to "increasing from x to y to z." (That make sense?)
Maybe, at one time, if you had first-class functions and map/reduce/filter, you could say "hey, this is like Lisp!" But that's pretty much every language now. Saying a language is-a-Lisp in this way is not a meaningful statement. You might as well say C# is a Lisp, or C++.
The "big idea" in Lisp is not functional programming. That's nice and all, but CL showed Lisp could be just as good at OOP. The thing that makes Lisp "Lisp" is homoiconicity.
And by that measure, we definitely can't call JavaScript a Lisp.
Why not Lisp? I never understood why would people need any other programming/query/markup language syntaxes in the first place. The only part of Lisp that seems ugly are the ending stacks of closing parentheses at the ends of big code blocks.
If you want to persuade people to use Lisp, "why not?" isn't very persuasive. If you don't have a concrete reason why, and I'm not already using it, I'm going to continue not using it.
> I never understood why would people need any other programming/query/markup language syntaxes in the first place.
Because Lisp syntax doesn't fit the way everyone's brain works. If it fits yours, that's great. If it doesn't fit mine, well, you may not understand why I want something else, but it's crystal clear to me. Going broader than you and me, it's my perception that most people find Lisp syntax non-intuitive. That's why people need other programming language syntaxes.
But, if you're going to extend it to markup languages, I will give you this. Once you have seen S-expressions, XML looks disgusting.
Wow, I'm currently in Korea and I did not expect Naver to have projects like Lisp implementations at all. Their services (map, search, ...) are very common here, but from the outside it looked more like a boring company.
Great write-up. They also mention Tamgu, another language they developed, with native Korean language string support (`ishangul()`, `romanize()`).
I'm actually pretty fascinated how someone was able to get this project hosted on Naver's Github at all. It's probably not coming from corporate judging by how informal and personal the language is (and also that there's only a French and English version), so it's probably just the passion project of a random employee or contractor. Interesting that Naver lets them host it under their public brand. I can't imagine the Google of the 2020s allowing anything like this in under their public brand.
I work in a laboratory specialized in Artificial Intelligence that belongs to Naver (NLE). These two languages are used in many research projects, especially for document processing before applying ML methods. We used Tamgu for instance in Machine Translation and in Sentiment Analysis.
We have also published in the past datasets for conference papers, that required the tools to be open source, so that people could reproduce our experiments.
This year for instance, we used the Prolog engine in Tamgu to produce a dataset to train a transformer on inference.
The process to make them open source was quite thorough and quite painful, but I cannot complain.
The case of LispE is little bit different, I created it to have a more flexible platform to experiment with functional features, which I could not do with Tamgu, which is too large now.
The blogs are simply a way to make these tools more visible, and since I'm French, I usually write them in English and French.
Awesome! Thank you for going through whatever red tape was required :)
To be clear, my description of the language as "informal and personal" was not meant as a criticism - I love it. It's just so different from the fake-enthusiastic professionalism that is usually mandatory from corporate-branded projects like this. Hats off to you!
I had left some comments on this duplicate <https://news.ycombinator.com/item?id=33453020>, and am admittedly not sure if I should duplicate the comments here, which seems to have more activity. But in summary - this article really conflates implementation and language; in particular, the "mysterious link between Lisp and OOP" is that you can write the evaluator in an object-oriented way, which you also can in a functional way, procedural way, relational way, and so on.
I used to love programming in the Macintosh Common Lisp environment. When the Mac moved to the PowerPC architecture there was a gap. Also at that time nouvelle AI labs moved to the PC architecture for access to embodied systems (robotics).
Unfortunately on PC Allegro Common Lisp seemed the only viable option. I still think it could have been a great success, but the company pursued a business model at the time with hideously expensive licenses (the intrusive phone sales campaigns didn't help their popularity either). By the time the Lisp ecosystem recovered, many had moved on.
MCL also moved to the PowerPC architecture. But it was later lost when there was the move to Mac OS X and Intel. The Open Source variant Clozure CL lacked the commercial backing and the nice IDE. Today the only really good GUI-based Lisp for macOS is LispWorks, which is expensive - but it is available on the latest macOS and the latest hardware. Clozure CL struggles to find maintainers.
The PC with Windows had Allegro CL, Golden Common Lisp, Corman Lisp and LispWorks. Of those Allegro CL and LispWorks are still available, though expensive.
Normally I skim these write-ups and then move on, but something about this time finds me exhausted. Enough already. I was a huge proponent of XML and back in the day I would also evangelize its capabilities, its malleability. "What a great language for defining data structures that isn't tied to any physical storage requirements." Regex and enum restrictions on attribute values? Okay cool. Substitution groups? Woah. But then y'all started saying "I can't read this" and "angle brackets are too expensive" and suddenly the XML wave just receded back into automotive and logistics, and the world stopped complaining.
I think it is time to accept that the world doesn't need Lisp. It might be your passion. It might just click with your way of thinking. That's all great, but it is still an existential crisis and you need to deal with it. The world is humming along just as well without esperanto and if it completely disappeared from monthly meetups, the world wouldn't notice.
Trust me, I have been to the brink of destruction and waking up the next day is hard, but I have lived it and I know: it is possible to leave behind those things that you think define your being, your identity. You will not fade away completely. Instead, you will find that your existence can have meaning in other forms.
Oh I see you brought a chess board to a basketball game. Okay cool, but just set that down and let's see if we can still have fun with this other game.
Strangely, it resonates to me in the context of finding "The Best Note Taking App" buzz. Whoa, X has backlinks! Yay, but Y is open source!
At the end of the day we all open the default system notepad.
For me, it's gotten to the point where Lisp is one of those "iykyk" things. Why it's so great can't really be put into words. It's a combination of factors, and... it's a feeling of thoughts flowing into code, of bringing a program into existence through dialog with the machine, expanding and refining it through that same dialog.
Gerry Sussman once said of Scheme something like "I want a good language to talk about programs with my friends, and that goes for both my human friends and my electronic friends." Lisp is probably for you if that's how you see programming, as a fruitful collaborative discussion with your electronic ally. If you see programming as "translating business requirements into code" or somesuch, you know where to find Java and you will probably be very happy with it. I don't care.
What would be the challenge to write OS kernel in Lisp?
Just X86, for the sake of umm simplicity, something like xv6:
https://github.com/mit-pdos/xv6-public
Yes, I've read about Lisp machines. Sounds like a super expensive machine only accessible by big-budgeted research companies.
Most of Lisp folks on the net talk about how homoiconic language is elegant, or how REPL makes development faster, or how useful Lisp is for automatic theorem prover etc etc but very rarely I see Lisp folks talk about system programming, unlike C/C++/Rust folks.
It is? That didn't stop Genera, Interlisp, Movitz or Mezzano to name a few. Outside Lisp there's also Smalltalk, Oberon and Singularity to name a few operating systems with GC.
Compared to the other pauses kernels make? Biscuit (POSIX in Go [0]) introduced at worst a pause of 115 microseconds and a slowdown due to GC and safety checks of 15%. But the forementioned systems don't have a kernel/userspace split; Microsoft measured the split made a server 25 to 33% _slower_ [1].
What I like about Lisp is that, for example, a configuration file can be written directly in Lisp (as opposed to, say, XML or JSON), in which case it can simply execute itself (i.e. without the need to have a separate interpreter to parse the text and to apply the configuration settings) - and it still would look like a configuration file rather than a piece of executable code.
Google (ITA Software, used by travel search engines), Quantum Computing companies (HRL, Rigetti…), Ravenpack (big data analysis), SISCOG (metropolitan planning system), the ScoreCloud app (play your instrument, it writes the music score), Opus Modus (music composition), pgloader (from Python to CL), industrial-grade theorem prover, and so many more…
> But nobody would objectively claim that Cobold is not dead
As long as production legacy systems exist in Cobol which people actively maintain, you can't objectively say it's dead. You are either confused about what 'objectively' means, or what 'dead' means
That said, Cobol is not alive in the same sense that Lisp is alive. There are certainly new interesting Lisp projects being developed today :)
the two points are hard to take together since no one "talks" a programming language natively. the important point regarding lisp is that it offers a unique value proposition for programmers. it is for this very reason still kept alive by the very programmers (new and veterans) that realize its value. these programmers improve existing solutions as well as start new ones, including commercial/industrial applications
> Could it be that Lisp is not dead because the people that started learning programming when it was popular are not dead?
I think that this kind of questions is derived from some kind of ignorance of one mathematical principle. If some mathematical law is discovered - it works, no matter how many active users it has. Lisp will never be like Python 2 which is definitely dead by all measures. A word "Lisp" as a name of programming language does not even have a certain implementation because "Lisp" is not "Common Lisp" or "Lisp 1.5". The word "Lisp" is just an idea, an extremely rigorous mathematical idea, this kind of things will never die.
You can't just leave us hanging there! Tell us more. What type of problems do you solve with it? Was it hard to get others on board with the idea of CL? Are you happy with your decision of choosing CL for FAANG work? Any advantages/disadvantages you observed during your work?
Clojure is pretty sprightly, perhaps even prolific, surely. For example, if you're in any way interested in databases, you will have come across https://jepsen.io/ who do all their testing using Clojure.
The proof is not in the pudding, but in the eating thereof. Thus: "the proof of the pudding is in the eating". In other words, someone having eaten the pudding, presumably without much ill effects, validates that the pudding was of a-OK quality.
tl;dr The parenthesized NPN (aka s-expressions) turns novices off to
Lisp but in fact facilitates side-effect-free, syntax-free versatility.
The long-winded code snippets author uses are terrible.
Compare with Rust and Go. Rust and Go devs write articles evangelizing Rust but that's not all we see. We also see posts about so many useful Rust and Go projects too.
How can we see a similar trend for Lisp? And no, it cannot be writing a Lisp in a Lisp or writing a Lisp in your favorite language or writing your favorite language in a Lisp. I am looking for useful projects that do something useful for users who can't give a damn what language the project is written in.
I searched https://github.com/topics/lisp but a vast majority of the projects there are not software used by actual users in the wild. Most of them are projects that teach how to make a lisp or documentation about lisp. There are some useful software like browser, editor, etc. in there but they are few and far between.
I know Reddit was written in Lisp but it isn't anymore. So that's a bummer.
Does Roomba still run on Lisp? I can't find out with some quick searches.
HN is written in a dialect of Lisp so that is one example. Can we have more such examples? Even better would be open source examples where any college student can contribute?