I have an opposite argument - no other file manager ever worked for me and I tried and keep trying so many. And not because Dired "is so much better" or "far more capable", or "has better default keybindings", or due to my muscle memory or Stockholm syndrome, no. It's because I can always introspect every single feature of it, override any command, integrate things with any other packages.
I honestly think that we (programmers) collectively went backwards when we tried to abandon Lisp. Why aren't there [popular] apps with a built-in true Lisp REPL for file management, email, version control?
Misunderstanding (or complete incomprehension) of Lisp lead us to the mess we're in today. Some may say: "people made their choice", etc. Well, like so many times in history, majority is not always right, but quite the opposite. We spent almost 2000 years building with inferior Portland cement, which degrades in seawater within decades, instead of using techniques perfected by Romans. We keep piling the crap, making CO2 emissions even worse. And only because we lost the recipe. The Pantheon built with Roman harbor concrete that strengthens in seawater still stands. Emacs is the Pantheon of software - the monumental example of what we've lost, the shining display of continuous progress in a world of regression.
It is heartbreakingly sad because there's now an entire generation that has no clue, because they have not witnessed the decades of callback hell. They don't know anything (or wouldn't even want to know) about "Beating the Averages", Greenspun's Tenth Rule, Gabriel's "Worse Is Better" and how he was so conflicted about his own essay that he spent a decade writing rebuttals under a pseudonym.
Lisp won't ever die, but it will never regain its former supremacy. Because for humans, economic/social reasons matter more than technical merits.
> does everything break on updates and need fixing
Emacs is a kitchen and emacs-packages are recipes - they come with the exact instructions (source code). If you try to cook fifty different meals all at once, your kitchen inevitably would be a mess. You need to know what you're trying to cook and how to work the recipes, and that comes with experience. No starter kit gives you a structure to un-mess your kitchen magically. Every sufficiently complex Emacs config is a system - a composite interweaving network of thousands of expressions, millions of code lines - it is the Space Shuttle equivalent; Neovim is like a simple twin-engine and VSCode is like a Cessna in comparison. Updates break your Emacs, I update things multiple times a week and rarely anything breaks (I consume over 350 packages); when things stop working - it doesn't usually take even a minute to figure out what's up. Yes, it does happen, but not as often as you painted it. On the other hand - when I need to get something done, there's no other tool in existence that can help me better.
TBF to the parent, I also started in spacemacs, then doom, before rolling my own config some years ago, and my early experiences also felt like upgrades were really hard to deal with and often breaking.
I think most of that was because I didn’t understand emacs itself very well, and doom or whatever is an entire extra layer of code and idioms on top of that. Start adding in any custom packages you’ve installed and things get well outside of the realm where a beginner can comprehend them.
Like you, I also now have a pretty large number of packages, and rarely run into issues on update, with any issues that do occur being easy enough to fix. However, I think a lot of that comes from at this point having built my own emacs from the ground up, so I understand what all the components are doing, mostly…
> I do wish that Emacs was more popular with LLM technologies.
Let's reword this a bit: "I wish Lisp use was more popular with LLMs...", because using Lisp REPL with AI is such a "life hack", I don't get why more people don't do that. When you give AI a "true Lisp REPL" it works wondrously - it stops randomly guessing and starts empirically understanding the problem and the code - saving time, tokens, your mental energy. And with Emacs' text manipulating machinery on top of that, things can get seriously interesting.
Nothing's wrong with it. It's just incomparable categorically. Just like you can't really equate a photo-editor and the web-browser. Sure, there's a way to do photo editing in the browser, still will be weird to compare them.
> Neovim has been much better
In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
> I just want a good text editor
Is that implying Emacs doesn't have "a good one"? You probably just have not discovered some mind-blowing features of the editor. It is hands down the best-known machine ever designed to deal with plain text, nothing even comes close. Indirect buffers alone are such a brilliant idea, I have zero clue how people ever exposed to that power would willingly abandon it. I get it though, building a text-manipulating theater orchestrated by Lisp is not for everyone. Unfortunately, most newcomers get attracted to Emacs hearing "how powerful an editor it is", without ever learning what exactly makes it as such.
That all makes sense. I wasn't trying to attack Emacs or defend Neovim, for the record. I liked Emacs and didn't have any problems with it (except some window jankiness). I was mostly just curious about the ecosystem.
The big reason I switched is because a lot of the big features of Emacs (org mode, magit, "living" in Emacs, advanced text manipulation, the extreme extensibility of the software) were things that sound really amazing on paper, but in practice I just don't really need/use/care about, and that's just my preferences. But once again, Emacs is cool and I totally respect what it can do.
Missing the point - it's not about "attacking/defending" - Emacs and Vim just can't be compared categorically, the core of their design is about two dissimilar, unrelated concepts. Vim's augmentation of modality is absolutely brilliant, beautiful model, enormously practical idea. Emacs rooted in another incredible, powerful idea - practical symbolic notation for lambda calculus. Comparing them plainly from their "text editor" aspect is wrong - it creates wrong perception of they are about.
It's almost invariably about the trade-offs, without knowing what they are and how to navigate them would remain a highly debatable topic.
You have fixated on a single (albeit voluminous) aspect of things to make a choice. But there are dozens of other things we can drop there and steer away from Emacs with wrong conclusions, e.g. Emacs has mail client capabilities, and for anyone unfamiliar with Lisp, it might be obvious - more specialized email apps would look far more capable. But for an experienced Lisper, no specialized app would ever suffice. Particularly because Lisp allows them to adapt things with extreme precision, specifically for their use cases.
> The big reason I switched
You have switched (as it seems) without even understanding what it was about. It's not about Org, Magit, or any other "features" of Emacs. The main idea is and always was the Lisp interpreter. For someone like me (staunch Lisper) Magit is not some "packaged", ready-to-use piece of software, it's a set of libraries I can use. I can easily incorporate just about any Magit function into my workflow directly. I don't have to submit patches, I don't have to ask anyone's permission, I don't have to guess - the source code is given, I don't even have to save my experiments anywhere - I can just start typing Elisp code in my scratch buffer and eval things in place. Similarly - I use Org-mode for a bunch of things that may sound absolutely unrelated - I consume HN, Reddit, Jira, GitHub, Slack and other content in org-mode derived buffers. Why? Again, because of bunch of APIs, functions and commands that Org provides. I can for example easily retrieve any HN thread and extract all the URLs people posted in comments, and inspect each in-place - takes me a keystroke. Or I can send the text to an LLM - without ever copying and pasting, without context switching, without losing focus. No other [popular] piece of software ever granted me such enormous power and liberation.
I am absolutely so grateful to my younger self for forcing me to grok Emacs and Lisp, and I will never understand the sentiment and the "reasoning" of people moving away from it (after being exposed to its absolute supremacy over plain text). Realistically, there's never switching away from Emacs for me, that, unless a better Lisp engine emerges at some point. And btw. I am a die-hard Vimmer. I use vim motions everywhere - system wide. They permeate my editors/IDEs, web browsers, terminals, and yes, even Emacs. And I use Neovim as well - it works well when I need to reach for it - like I said: it's not a comparison.
> In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
Unless this is specifically what you want to do with Neovim, in which case you'll probably just use Emacs anyway, Neovim's inability to do this is probably not a strike against it. As royal__ says (https://news.ycombinator.com/item?id=48537120), they are just interested in a good text editor, not in raw computational power.
Does it really matter? There's a point in every Lisper's life, a threshold after which the question becomes immaterial - you'd stop thinking about intricacies of whatever Lisp and focus on the platform specifics instead. Any given day I might program in three-four different Lisp dialects, e.g. Clojure/Clourescript, Fennel, Elisp, Janet, etc. and it practically feels like I'm using the same PL. While switching between TS and JS (same family) never feels even close - there's always some mental burden.
not philosophically, but certainly practically. To double down, if all lisps are roughly equivalent from a language POV, then you'd want to pick the one or two that will give you the most practical advantage (libraries, documentation, dev environment, etc.)
I would call these different dialects of Lisp. The data doesn’t have to be a function. It’s illustrative. The patterns of application still work. What’s the difference if delimiters are different or if you are calling JVM libraries? The high-level ideas are still right there. Consider JavaScript. It is definitely not a Lisp, but if you model it as Lisp in C’s clothes, then all of a sudden IIFEs make total sense. The point is that it’s a helpful mental model for languages other than Lisp.
Limitation is the wrong way to think about things when computational equivalence is in play. It's about mental foundation. Lisp at its core is like driving a Turing machine, Clojure is not.
If the difference didn't matter, we wouldn't have so many different lisps. Obviously the difference mattered enough to the people that created Common Lisp when Scheme already existed. Rich Hickey thought it mattered when he created a completely new Lisp instead of just porting Scheme to the JVM.
> If the difference didn't matter, we wouldn't have so many different lisps
Literally the opposite. We can make and use so many, because writing them is more or less the same. We can quickly throw together a new lisp for a new platform or such and use it without problem.
Technically when you write in the domain, you are effectively making your own Lisp and then using it. It’s one of the amazing things that macros can do.
The most infamous two letters of our time - humans do not like machines, and absolutely hate those who do.
> I voiced a valid concern
Not unwarranted. When you treat a homoiconic language just like any other, LLMs do sometimes get messy with paren-balancing, but most models correct it on a second-third try. You still get some benefits - e.g., Clojure is the most token efficient mainstreamish PL.
To get the most benefit from it, one must teach the model to treat it just like a human programmer would. It makes no sense to treat Clojure like Python or Go, or C - it's like ordering a pair of swim fins and jumping into water with the unpacked box. Lisp dialects shine when you use the REPL (true Lisp REPL - not some faux-repl like Python's), so you have to "teach" the model a way to operate the live REPL, not passively reading/writing "static" code that's fed into it batch-style. When you do that, models not only get much better grasp of where the syntactic elements should be, they start reasoning about the program in a way more interesting fashion, empirically evaling pieces on the fly, interactively - without juggling state, without compiling, without even having to save things (until proven to work).
Does that make Clojure "the best LLM-suited PL"? Not really - there's simply no such thing. For sure though, the homoiconic nature of the language absolutely makes it enormously interesting and well-suited for it.
I bet you're just treating it like any other (non-homoiconic) language. An agent that edits files and re-runs `clj` is doing something fundamentally different from what a Clojure developer typically does. When you give the agent a REPL - things get far more interesting.
Well, that's not how a Clojure dev normally would write it. If you're not using the REPL (with or without AI) - you're missing the point/misusing the tool. Therefore "remains shockingly bad" perspective is unfair - it's like using a screwdriver to remove nails while complaining that it keeps bending.
I'm happy to hear any thoughts you have on the best way to make use of it. Presently I use emacs and cider but I'm not altogether unhappy with IntelliJ or VSCode
So yes, you're already using Clojure REPL with CIDER, right? Then why not make AI use it as well? You can do that directly from Emacs, with ECA¹ for example. Which on its own won't change anything - it still be in that batch-style mode - LLM spawns process -> reads stdout/stderr -> spawns next process. What you'd need on top of that is an MCP that "understands" nrepl. You can find many different ones, I built my own (written in Clojure, runs with babashka)²
Alternatively, you can use Dmitry Sotnikov's agentic tool³. Dima is a well-known Clojurista (with published books, etc.) I have not tried that myself because I prefer staying in Emacs, but it might be even easier choice for someone else.
It's okay when you use it just like any other PL, which is roughly the Unix/pipe model - batch-style. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in-between the calls and in files. Each tool invocation is stateless.
Things get far more interesting when you give an LLM a true Lisp REPL. LLM stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens. And you get to watch it solve things interactively, e.g. I often let AI poke through our UI (via Playwright-driven Clojurescript REPL), while monitoring situation in k8s - through nrepl port, connected to Clojure REPL.
Oh, come on. I get when people complain about AI-assisted writing. It's mostly about signal-to-noise. Yes, AI makes it trivially cheap to produce "correct but empty" content - articles that are technically accurate, well-structured, and say absolutely nothing a reader couldn't get by prompting an LLM themselves.
Yet sometimes you do need to see a genuine human struggle, ideation, and a real problem behind the article. Let's try not be dismissive off the bat. I understand your style objection is a proxy. Your actual complaint is probably the feel of absence of a specific, earned perspective. Perhaps, it "doesn't speak to you" because you have not encountered the overlapping problems that article may help you with.
That isn't prose - it's educational, informational, well-structured and has code snippets. Let's not devalue someone's genuine work only because they decided to use AI-assistance - there could be legit reasons, from language barrier to lack of time. Good writing is hard. With and without AI. Not everyone commands the skill of writing, let's not rob them of the opportunity to cultivate it. Sometimes, it starts with dull, spiritless paragraphs.
Really? I've used dozens of languages and honestly, I just can't wrap my head around how ugly Lua code can get. At first, I tried treating it as "javascript with no bad parts", turns out, modern JS is far, far better than 1996 JS and nicer than Lua. The most annoying part about Lua is that I never know how to format it for better readability - should I add line breaks, or not, etc. lua-fmt often just makes it worse.
When I found Fennel I immediately moved to it, even though it was "experimental". Since then, I just don't want to deal with Lua, aside from some small one-liners.
I honestly think that we (programmers) collectively went backwards when we tried to abandon Lisp. Why aren't there [popular] apps with a built-in true Lisp REPL for file management, email, version control?
Misunderstanding (or complete incomprehension) of Lisp lead us to the mess we're in today. Some may say: "people made their choice", etc. Well, like so many times in history, majority is not always right, but quite the opposite. We spent almost 2000 years building with inferior Portland cement, which degrades in seawater within decades, instead of using techniques perfected by Romans. We keep piling the crap, making CO2 emissions even worse. And only because we lost the recipe. The Pantheon built with Roman harbor concrete that strengthens in seawater still stands. Emacs is the Pantheon of software - the monumental example of what we've lost, the shining display of continuous progress in a world of regression.
It is heartbreakingly sad because there's now an entire generation that has no clue, because they have not witnessed the decades of callback hell. They don't know anything (or wouldn't even want to know) about "Beating the Averages", Greenspun's Tenth Rule, Gabriel's "Worse Is Better" and how he was so conflicted about his own essay that he spent a decade writing rebuttals under a pseudonym.
Lisp won't ever die, but it will never regain its former supremacy. Because for humans, economic/social reasons matter more than technical merits.
reply