> they bother to have a Klingon language consultant on staff
I realize there's a fair bit of money to be made, and also that many people are super invested in their favorite science fiction series, but the fact that "a Klingon language consultant" is a real thing still makes me think "wow!".
I'm currently reading a book written by the guy who created the Dothraki and High Valerian languages for Game of Thrones. He had to make what already existed in the books for, so there were a few things already set.
He was a consultant in the show as well as he was the one who had to get the actors to speak it well.
The book is called The Art of Language, and if you have an interest in conlangs, you should give it a try.
I think it is worth noting that Richard P. Gabriel wrote the forward to the book in question, and he quotes Guy L. Steele in that forward -- from the paper that you are suggesting the author might like.
Or you mean he'll probably already know about the paper? Yes, I guess that's probably the case...
I did not think about it too much to be honest, I just knew that article and thought that he would really like it if he had not read it. But I can imagine somebody writing a book on the history of Lisp has already read probably all articles around on the topic.
Yup, I know of that paper. The amount of (not or partly acknowledged) reading I've done for the book borders on the insane so I do welcome these suggestions, I've forgotten 80% of what I read and learning what others value helps me put together a "you really should revisit this" list :)
> - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished.
Can you give specific examples of "what a typical user expects" that are missing from Emacs-based programming environments (SLIME, and/or others)? I'm not suggesting there aren't any, I'd just like to know your list.
Lisp does not have that much syntax for highlighting to be a problem.
Lisp is also a symbolic language. Meaning the code work on symbols, not data, only at evaluation the value of the symbol is known. There’s a lot of symbols manipulation routines like macros, intern, package loading,… that prevent to statically know the code.
The problem is not a lack of syntax highlighting per se, but the inconsistency of existing syntax highlighting. This is especially annoying in Common Lisp due to the existence of symbol macros, where syntax highlighting would be immensely helpful.
I get that there are issues with symbol manipulation, but AFAIK language servers already evaluate code, even if not for syntax highlighting. I view this whole thing as an issue caused by the REPL workflow, not the inverse. Not to say that I would be willing to give up said workflow but it could certainly use improvements.
- Ease of setup and install. Turnkey. Good defaults.
- Non-buffer based workflows.
- Easy access to settings.
- Easy ways to change or switch my compiler.
- Integrated with typical lisp tooling for library, system, and package management. (For example, what Emacs button do I press to set or clear my ASDF compile cache?)
- Better integration of the profiler and debugger. When a Lisp error happens, yet another buffer pops up (breaking the arrangement of all your code windows you set up), this buffer may not even be the only one (but the others are hidden somewhere), and it's not clear what you can even click or expand to see more information (there's a tremendous amount, extremely non-discoverable).
- Good getting started: built in guide for structural editing, REPL workflow, etc.
...and much much more. I say all of this as someone who basically has only used and invested in Emacs for 20 years. I love sharing Emacs with people who like weird technologies and rabbit holes, the real "hacker"-type people. I hate sharing Emacs with people who want to be productive in an hour or so with a Lisp project, because I know within 5 minutes they'll be disappointed, and never get the best of the experience because it's too much uninteresting investment.
I prefer writing Lisp with Emacs+SLIME over anything else. It's extraordinarily powerful, and with enough grit, you can get it to do almost anything you want. But I'm also jealous of people who get to use, say, polished JetBrains products whose goal is to try to give you the best experience possible for your specific programming language.
JetBrains IDE plugin for Common Lisp: https://github.com/Enerccio/SLT (I'm sure you saw it before and I don't know how polish it is, and I'm pretty sure it has less features than Emacs&SLIME, yet, but I must link it for reference. Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.)
We all can google. Have you tried to install the plugin? It doesn't support the current version of the IDE and as the last commit was 8 months ago there is no hope it will get such a support soon.
TBH no people don't google (what they don't expect to see), repetition and showing links is necessary. I hadn't followed along. Hope it will get contributors.
I mean the following with all due respect—and I have a lot of respect for your many efforts and contributions—but it will sound a little blunt, especially as a written comment.
"We have one," no, this is a consistent problem with people who evangelize Lisp. We have had "IDEs" for decades. Most of them, except the couple commercially supported ones, were "experimental", "incomplete", "buggy", etc. This includes the one you link here.
Are these projects valuable as a starting point for other hackers to join in and help? Sure, maybe. Are they helpful for a new programmer? Almost always the answer has been "no". I have first-hand experience subjecting a programmer to one of these tools, and I myself getting incredibly frustrated at how broken it is. Imagine somebody completely new.
You in particular love to advertise these different projects as a form of Lisp evangelism. Advertising the projects is great—I hope they attract helpers—but I think your language around them is deceiving.
> Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.
"We have one" in the absolutely most rudimentary interpretation of that phrase. What we don't have is a working JetBrains Common Lisp IDE suitable for production use.
In order to try to promote a realistic view as to why Lisp doesn't attract more programmers in 2026, I myself will continue to point out Lisp's highly substandard tooling offering until there's an actual product that works. Any Joe can spend a weekend making a 1/2 baked, proof of concept IDE. Even more so now with all the AI vibecoding tools we have at our disposal. It takes much more to make something that checks all the boxes.
ACK, allright. I just want to point people to stuff. Create emulation. Show that the ecosystem is evolving -in the right direction even, maybe. That we are not doomed to stay with Emacs&SLIME. A few years ago, we didn't have SLIMA, the VSCode plugin, Jupyter and JupyterLite kernels, the very useful ICL, nor CLOG, nor these incomplete IDE attempts (Intellij, Sublime…). How good is the new Zed plugin BTW? https://github.com/etyurkin/zed-cl
(I'm not even evangelizing in these comments so thanks for the feedback I guess!)
I was already aware of its relation to 'ed' (having had to actually use 'ed' in ancient times). However that doesn't change the fact that it does stand for "stream editor".
After reading your post, I thought "That doesn't seem right, I remember it specifically being referred to as 'stream editor'", so I went looking.
> There was strong cultural pressure to be able to write perl in as few bytes as possible
Hard disagree. Many Perl programmers enjoyed engaging in code golf (always just for fun, in my experience), but in my nearly 30 years of programming Perl, I never encountered anything that I would call pressure to do so -- not from anyone.
I realize there's a fair bit of money to be made, and also that many people are super invested in their favorite science fiction series, but the fact that "a Klingon language consultant" is a real thing still makes me think "wow!".
reply