Yup. Reminds me: "studies prove that horses improve health and increase the lifespan...". Bruh, people who live around horses are probably those who either have to work hard all day, or have good amount of money to take care of their health. Readers are healthier because they more likely to grow up in wealthier environment to begin with.

One side of me wants to remain skeptical - knowing how much stuff there exists in Org-mode and Magit - piles and piles of different workflows thousands of users had to go through over the years - a bunch of well-trodden paths.

At the same time, I am well-acquainted with the power of Lisp and its communities. Give Lispers a powerful engine, and they'd take it to the moon and beyond. Lem's been steadily developing over the past few years and slowly been adding users, at least I keep hearing of curious people trying it. Meanwhile Org-mode's core feels almost stagnant, and it's one of the "killer apps" of Emacs. Lem might be on the brink of making things so appealing that it would be hard to refuse it. For some lispers that's already the case. I'm wholeheartedly welcome this challenge to Emacs' hegemony. I love Emacs and I hate Emacs, because sadly (or otherwise) I don't see any practical alternative for it - anyone who thinks nvim or vscode are even in the same room are clueless. Perhaps, the time to seriously consider Lem is almost (?), already (?) here.

That's still not homoiconicity. It reminds me old Stuart Sierra's presentation from Clojure/conj¹. Around 6 minute mark: "Adding eval to a language, even successfully, does not count as homoiconicity"... "and you didn't even succeed at that..."

---

¹ https://www.youtube.com/watch?v=o7zyGMcav3c

It doesn't look like your real goal was homoiconicity at all, but rather "stay in JS semantics, keep the JS ecosystem, and build structural editing over any language". Homoiconicity is a word you grabbed to borrow from Emacs's fame, but not a requirement you're were ever trying to satisfy. If it was the actual requirement, there are dozens of options that exist already - Squint, cherry, Clojurescript, Scittle, Fennel-to-JS, even Gleam - any of them gives you code-as-data cheaply.

That's an orthogonal problem. It's almost trivial to set up Org-mode so all your personal notes are always encrypted on disk.

A specific language is not the point - to implement anything similar to Emacs, you'd need a homoiconic language or at least a language that gives you live, reflective, late-bound image with code-as-data. Without that single aspect tons of things simply and inevitably (as history shows) will get complicated.

Why we have not seen such differentiator with VSCode? Because of their design choices - the extension language and the editor internals live in different worlds behind an API boundary. Emacs essentially has no such boundary. That's the power, and also a consequence of the image + homoiconicity combo.

Lem is great and I'm happy there's finally something out there to challenge Emacs' hegemony, yet pragmatically, unless someone builds a way to run Elisp in Lem, it's unlikely to overthrow Emacs anytime soon, and that's just not gonna happen.

Org-mode, Magit, and thousands of packages aren't just "Elisp code" - they depend on Emacs' specific buffer model, text properties, overlays, markers, the display engine, process handling, and countless quirks packages rely on (intentionally or not). A Lem Elisp interpreter that didn't also reimplement all of that faithfully would run trivial `.el` files and choke on anything real. At that point you've reimplemented Emacs inside Lem.

Elisp is not the biggest point here and Neovim proves that with pivoting to Lua; the crux is the runtime and the corpus, and reimplementing those is the actual mountain. That is real ecosystem for whatever reason you're choosing to simply ignore.

Perhaps they could, but let's not make generalized assumptions. I don't know about you, but for me English is not a second, nor even a third language, and for people like me it is absolutely beautiful yet a supple and extremely nuanced tool for thought expression. I wouldn't risk unleashing the naked nature of my prose on anyone, it may not be easy on the eye - I liberally use all the tools I have in my text editor - spellchecking, thesauri, dictionaries and translation, etymology lookup and yes, LLMs as well. Would you complain that my texts overuse synonyms and that's just "annoying"?

You're honestly acting like some impetuous child demanding that the world revolve around them and their likes and dislikes. You're asking for a "human connection", while at the same time granting them zero empathy for their effort - however sloppy it was. The choice is yours - nobody's forcing you to read it. Shitting all over someone's (no matter how small) genuine work is disingenuous, not to mention that it is pointless zero sum - nobody gets any kind of satisfaction, none of the involved parties learn anything new.

For me, the article didn't "speak much" at all; I'm not defending its value. For someone it may feel different - I quickly went over it and that was all. I (like many of us) have been very inundated with LLM-generated texts, but frankly, people seem to eagerly label just about anything as AI-slop. It is getting more exhausting than simply dealing with text. Sorry, but we can't uninvent the damn thing back into the hellhole we found it in. Let's try to be nicer to each other in this brand new world.

ps. I just read the whole article. It is fine and it doesn't look like it was written with sloppy vibes. Honestly, you're complaining just for the sake of it. The amount of whining about AI-slop is getting more exhausting than the problem itself.

How the heck anyone doing anything remotely related to programming can't be familiar with vim navigation? And if they're familiar what does "meh" supposed to mean? It's like having an "opinion" about where the Tab key sits on the keyboard: "I hate Tab, it was a stupid idea to put it on the left side..."

Software development is not purely technological discipline, we deal with socio-technological problems all the time. That means we need to consume and produce far more plain text rather than just code.

I mean sure, there are many facets to this and simply benchmarking and fretting about one's WPM won't magically make anyone a better programmer. But thinking it isn't important at all ain't right either.

Years ago I stopped typing anything longer than three words in anything but my editor, I just don't even understand why every programmer doesn't do that - it just makes perfect sense. The idea of automating copy+paste from any program into your editor and back is such an obvious thing, it feels stupid if you're not doing that.

> there are lots of little things that make vim live more comfortably side by side with modern GUI life than emacs does.

No disrespect, but honestly it sounds like you have never experienced the practical side of a Lisp system that permeates your OS. You just can't meaningfully compare Vim (or pretty much any other text editor) and Emacs, because Emacs is not a text editor, it's rather a text orchestrator. I for example easily build such workflows like "grab the url from one of my browser tabs and insert it", or I can get it from my browser history, or "retrive current thread I see in Slack and search for specific piece of text". Or placing the cursor to the plain text like "FOO-4142" immediately gets pattern matched and I see the popup with the Jira ticket description. That all I do in the middle of typing any text, like for example this very comment. I don't have to leave my editor, I'm not forced to do things how they dictated by other apps.

I use Neovim almost daily, it comes in handy for quick text editing in the terminal, and I love the idea of Vim in general - it's a beautiful, practical, amazing model and I use it everywhere, it permeates my OS - my WM, all my editors, my terminal and my browsers. But Neovim just can't be like Emacs, because fundamentally they are categorically incomparable. In practice that means that the "comfortably side by side" reach you're trying to describe goes further, because of affordances - building specific workflows that affect things on your local and remote machines is cheaper, quicker and simpler. I would grab any area of my screen and it gets immediately OCRed and extracted text pops in an Emacs buffer. It took me fifteen minutes to build that workflow. Getting done anything similar in pretty much any other editor wouldn't even occur to me - I wouldn't even bother seeing it as a problem that needs solving. Affordances shape the way you do things: https://news.ycombinator.com/item?id=48876315

While there are many reasons to perhaps stay away from Emacs, realistically, for any serious Lisper, there's just no other alternative - sadly or otherwise.

I think, collectively, as the industry force, we software developers having now to pay imperceptible price for disregarding the pragmaticism we had/have in systems like Lisp and Smalltalk. We standardized on dead artifacts: text files compiled into opaque binaries, restarted on every change. We rebuilt weaker versions of what those systems had, piecemeal, decades later, and call them innovations.

You don't notice the cost because it's spread out. Nobody ever gets handed the bill. Instead it shows up as little bits of friction across millions of hours of work: slow feedback, extra steps, tools that treat a running program like you can't touch it. We took the accidental limits of file-based, restart-everything development and assumed that's just how programming works. And quietly, all together, we paid a huge price for giving up the live, flexible systems we already had.

Emacs is one of the last mainstream artifacts that still embodies that old ethos. For serious Lisp work the alternatives are pale because they still treat code as text to be sent elsewhere, rather than a live system you live inside. This lock-in isn't some kind of nostalgia, it's just nothing else preserves that property.

I wish there were more Emacs-like systems, instead of dozens of tools that all trying to solve same or similar problems - how many different tools are there for Python alone just to unmess its cascaded dependency woes? Or look at the whole containerization tower - Docker, Compose, k8s, Helm, Nix - all because we've "forgotten" how to reliably reconstruct a running program's state.

TLDR: Don't ignore Lisp - it's not archaic, it's not "theoretical", it's practical, it works and it works well. And once you get some serious footing with Lisp, you'll sooner or later come to appreciate Emacs, and then will be forever frustrated that we don't build Emacs-like systems anymore. You'll hate Emacs and whenever you do, you'd be reminded that there's no better alternative in existence. Sadly or otherwise.

I've had the same complaints when I started. I think, realistically, every programmer who's learning Lisp after getting experience in a bunch of other languages has to deal with that. The mental overhead feels real. Yet, after a while, there's some psychological threshold - Lisp starts feeling more intuitive. At some point, there's just no turning back - nothing ever will feel again more readable than Lisp code. It's just like riding a bike. Once you "get it", there's just no way to "unget it" back.

Working with Clojure is an absolute delight. It strips down all the dogma and let's you deal with the "business logic" as if you're cooking steak using no BS ingredients - meat is meat, herbs are real, stove is hot.

Why would I ever choose bash for writing anything slightly more complex than simple redirection, when I can do things in way better fashion with babashka. Why would I wrestle a YAML CI pipeline that only fails on push, when I can drive the whole thing from a babashka task file, run each step locally in the REPL, and actually debug it?

Why would I ever deal with Lua, if I can't even format it for "readability" - no matter how I do it, it just looks darn ugly, and luafmt often makes it worse. Why, if I can just slash down dozen lines of Lua boilerplate compressing it into a three-liner Fennel macro? With Fennel, I can interactively poke through elements of my WM through Hammerspoon on Mac, and that's just bananas.

Why would I ever deal with JSON, when EDN is almost twice as compact and far more readable - I can align things and treat data as a literal table. Besides, I can group, sort, filter, slice, dice, salt & pepper that data easily, without ever leaving my trusted editor.

Why would I choose to build a web-scraper in Python, when I can use nbb driving Playwright and go through selectors interactively, directly from my editor, as if it is a devtools console. And I don't even have to restart anything, deal with state changes, etc.

How can I abandon Emacs where I can just open a scratch buffer, type some Elisp and change the behavior of my editor, my WM, my OS and even things on remote computers. No other text editing environment works the way Emacs does - nothing even comes close. It feels like playing a video game, where my controller in my editor.

Why would I write Flutter UIs in Dart, fighting the widget-tree ceremony and endless build() boilerplate, when ClojureDart lets me express the same tree as plain data and hot-reload it interactively? The layout is just nested maps and vectors.

Why would I reach for C when I need to embed a small, fast scripting layer. Text parsing alone would be a regex nightmare elsewhere.

Why would I bolt a templating engine onto HTML strings, when Hiccup makes markup just vectors - so my views compose, filter, and generate like any other data, no special templating DSL to learn

And with all sorts of different runtimes and dissimilar Lisp dialects, it still feels as if you're working with the same language. The mental overhead when switching is so negligible. While switching between just JS and TS - which are supposed to be of the "same family" - feels quite annoying. Despite the fact that I've put years into those - far longer than any Lisp I've ever used.

Sure, nothing special about Lisp at all. Except that practicing Lisp can actually make you a polyglot. You'd realize that it isn't syntax that makes a programming language, but runtime and semantics do. After years of dealing with different PLs, I lost a preference for one specific language - I'd choose the runtime best suitable for the task, and then see if I can bolt Lisp on top of it. And these days, it feels like there isn't a platform left where you can't meaningfully do things via Lisp.

But like people coming to Emacs from Neovim may get confused why is nvim +term has only two modes, but this one has 5, what's the point? Without clearly understanding the problem, the knee-jerk reaction might be "this thing is an over-engineered BS", while in truth Ghostel isn't more complex because it's over-engineered - it's more complex because it solves more of the problem - the extra modes are opt-in tools for tasks nvim simply doesn't address. But it's not super clear how in practice use that leverage efficently.