iLemming

[they] couldn't possibly write good English?

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.

Look at the name. The author is unlikely to be well-versed in English prose. I'm quite certain you wouldn't like their "authentic" writing more than you hate their AI-assisted one.

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.

I know, right? When people respond to a sentence containing "vim", with "meh", I feel like going: "What do you mean 'meh'? Are you saying you never used sed, or haven't heard of manpages, or `less` and `more`? What kind of programming you've been doing so far?"

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..."

You mean to say programmers deal only with machines (and therefore code and shell commands) or something? Of course typing speed matters - we deal with Slack, Teams, emails, documentation, comments, LLM prompts, etc., daily. Sure no one's saying you must achieve stenographer's velocity or you can't call yourself a programmer. Still, typing speed has certain importance, it just can't be painfully slow, that's all. But thinking it doesn't matter at all is a manner of hubris.

I'm honestly not even surprised by the number of comments saying how unimportant is the typing speed for a software developer. What a bunch of bullshit. What the heck you've been smoking, friends? Speed of reading and typing text it is absolutely the hallmark of a good programmer. Consuming and producing text is not only about code - code is nothing but structured text.

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.

when I use Slack at work

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

so I don't have to use Emacs

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.

You don't have to imagine. Clojurescript exists.

I just find readability such a hurdle

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.

There's nothing "special" about Lisp and Lisp dialects, yes. Similar features can be or already have been implemented in other languages. Yet, after touching, using and experiencing working with a bunch of different stacks, I cannot simply ignore the enormous pragmatic level of Lisps.

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.

It's legit nice. I have gone through vterm -> eat -> ghostel transition and this is a winner. At least for now.

It would be nice to have some practical examples of how efficiently use its different input modes. On the surface the reasoning is straightforward - a terminal wants every keystroke. The editor also wants keystrokes for its own commands. These two desires are irreconcilable, so any editor-embedded terminal must have a way to switch "who owns the keyboard." That switch is a mode. There is no escaping it.

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.

the title fails to be meaningful

It's a weird flex to insist that the titles should always be extremely descriptive. It is already meaningful for the respected audience. Otherwise you can endlessly argue that a florist may not understand what "terminal" and "emulator" are, therefore it should be more descriptive for an occasional florist vising HN. For anyone who doesn't know what .el stands for, they'd click, see it's about Emacs and if not interested - close the tab and forget about it. Takes maybe a second. Not even a smallest imaginable deal - not big at all.

Yes, any GUI that doesn't provide any kind of RPC or composable API layer is almost a lost cause to me. I'd personally refuse to use it. With a caveat, though: on MacOS, which I absolutely abhorred in the beginning, having now been required to use for work (instead of Linux), I found the beauty of OSA (Open Scripting Architecture). Holy mother of Turing, I wish there was anything similar on Linux. I had no idea how amazing this thing was. I can fearlessly dig things out of even complex UIs for automation in ways that I can't ever dream to be able to do on Wayland. That still not an excuse - any serious UI should provide a functioning API.

fwiw, Clojure pretty much replaced jq in my toolbelt. Dealing with EDN is so much gratifying - it's almost twice more compact than JSON, it's far more readable; filtering, grouping, sorting, slicing data is so much more straightforward and actually composable, not to mention that I get to do that interactively, directly from my editor.

never had to do this

is not a defensible argument (regardless of what you use), see the relevant comment here¹

the bigger point is to get more precise and utilitarian control over text which I already discussed here in this thread², piping in and out of your editor buffers sometimes comes very handy.

___

¹ https://news.ycombinator.com/item?id=48876315

² https://news.ycombinator.com/item?id=48869558

"I don't think I've ever had" stance, about any problem is not a good argument. At some point you'd face them and the mental models shaped by the tools you choose, often force you to deal with them in a way that often creates small, subtle micro-annoyances. You won't even consciously notice them, yet they add up. You get constantly distracted, every time by small bits, your focus budget gets eroded without you even noticing it. You feel inexplicably tired at 3PM without any meaningful work getting done for the day.

In psychology there's a term called "emotional bank account model" - small chronic negatives silently drain the account, so by the time something "big" happens there's no reserve left, even though the big thing isn't the actual cause. That is I think why our field has notorious "burned out programmer" problem. We can't even explain the reasons - because the accumulation is diffuse and undramatic, people lack a narrative-worthy explanation, and the real cause is chronic negative-affect accumulation.

That is why it is important to seek ways for the "gratified productivity" where no matter how small your problem seem to be, you can find ways to automate it nicely, ideally reaching for solutions quickly. Tools do shape your mindset. Expertise changes what affordances you perceive. Experienced Emacs user when stumbled on a problem looks at a workflow and literally sees the seams where it can be pried open, the way a climber sees holds on a blank wall. Novices often don't even recognize the wall. It's not that Emacs "has this capability, but other tools don't", it's not about specific features, it's about the mindset. Experience awk hacker for the same "rename 20 files problem" may combine a complex looking single-liner and say: "who needs Emacs schmimax? ble...", the difference in the approach, but the result is not just the output but also the mental gratification - small problem fixed quickly. While a newbie would be doing it manually, and maybe even solving it faster, but there's no gratification. We are species of "tool builders" - we get excited from using tools, sharpening them each time. Menial tasks don't leave that sharpened mental edge, they "blunt" your mindset and accumulate frustration.

Emacs is not an editor. It's a Lisp-driven text orchestrator with a built-in editor. You can type your text in whatever IDE and still control everything through Emacs.

whoa, you can and absolutely should pipe things in and out of vim - it's natural. Emacs on this actually in disadvantage - it doesn't give you a built-in way for piping from and into buffers, but for that there is emacs piper script: https://github.com/agzam/mxp

I realized that I was typing the comment above in the middle of the night; finally, brain fatigue hit and I wrapped it too soon (thus some typos, sorry). That all was some "poetry." Now let me give you some concrete example cases.

1. You're typing a message to your colleague, and you're doing it in Slack, Teams, etc. Why? Why not use your trusted editor where you probably already have smart completions, quick spellchecking, thesaurus, definition and etymology lookup, translation and dictionaries, LLM integration and more.

Years ago I realized that and stopped typing anything longer than three words in anything else but my editor. But that forced me to copy-n-paste a lot, so I automated the process. I'd press a key in the middle of typing - regardless of what the current app is, the script simulates pressing Cmd/Ctrl+a Cmd/Ctrl+c; opens the editor buffer; inserts the text; I'll do editing; press a key - it goes back to the app; pastes the text. Stupidly simple, deviously efficient. Suddenly, my entire OS is my editor and my tool is "invisible" - like the article describes.

2. You're typing a message to your colleague. Now you're doing it in your editor, you want to share the url to the thing opened in your browser. What do you do? Normally, you'd switch to the browser, press another key to focus on the navbar, copy the link, switch back, paste the link. Goddammit, the url is cryptic. You, being a good teammate, want to add a description, now you have to go back to the browser to copy it. Then you have to make it into a markdown link format. Darn it. Was it parens and square brackets, or the other way around? We don't even realize how often we do this, because this simple action has become a routine. What's the point of arguing if mouse or vim or shortcuts is faster if the action is fundamentally flawed? For me, inserting a link in the middle of typing, from any tab in my browser is within a keystroke. It intelligently and properly formats it while retrieving the document.title.

3. Your colleague sends you a message: "Hey Jon, what about FOOBAR-41234?..." You know it's a Jira ticket number. But between FOOBAR-41345 and -41234 and a bunch of other recent ones you have no mental recollection of what that number is about. You go to your browser, navigate to the Jira instance, darn thing says you have to re-login, now you're going through 2FA - it won't even let you-in unless you find your phone and confirm it. All that effort just to look at the title. We all recognize this familiar flow, don't we?

Why even deal with this BS at all? Jira, Asana, Trello, etc. - all have CLI tools, you should leverage that. In my editor, whenever the cursor stumbles on a pattern like above, it immediately fetches the ticket description and shows it in a popup. I can quickly convert the plain "FOOBAR-41234" into a markdown, org-mode, whatever link format that has a description.

4. You're looking at FOOBAR-41234, you even see the description (because your editor is smart now), but how do you answer questions like: "what are the PRs related to this ticket?", "find slack threads that mention it", etc.? That stuff should be quick and easy. Do get annoyed whenever it takes longer than two seconds to answer any of these or similar questions.

5. You are pair-programming over Zoom. Alice (your colleague) is sharing the screen, you are reviewing some big unit of work. She's scrolling through the code changes, occasionally opening documentation, navigating to different sites, etc. You just can't bear constantly interrupting her with "slow down, I'm taking notes", "please, share this link", etc. After the session you frantically try to recall, but most of it is gone now, your notes are whacky, containing a bunch of broken urls and half-typed nonsense. Three weeks later it is a complete and utter garbage. Then you spend years debating of note-taking strategies trying to figure out what "works" and what doesn't.

That should annoy you. Darn it, if I can see it on the screen, why can't the computer "see" it too? It irked me, so I hooked up Flameshot, Tesseract, and Emacs and now I can select any area of my screen and the text gets OCRed and pops in a buffer. It's not always accurate, but it is quick and I don't even have to tell Alice to slow down anymore.

---

These are just a handful of examples, and I haven't even touched anything code related. Hopefully you can already see what I meant in my post above. Do liberate your text from the tyranny of complex GUIs, do get annoyed when you have to manually retrieve any piece of whatever. You're a damn programmer, computers and computer programs should obey your command, never forget that.

i don't wait on agents. ew!

You're conflating "what I do" with "what my job is." A bunch of my friends and colleagues are literally getting paid and forced today to use agents. There's no break from it unless they quit their jobs. I'm not saying I'm eagerly content and happy with this bullshit, alas, it is what it is.

Most programmers come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, terminal, in PDFs, Word or LaTeX documents. Code is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier.

Vendors are designed to own you and ownership can have different forms. Slack.app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their imbecilic, quirky wysiwyg owns you. Note taking app that keeps the data in their db and not your files - ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates. It doesn't become "invisible" like the article says, you just don't realize that you're "lost" yourself in it.

Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on your workflows.

Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.

Anyway, this should be a little more of a deeper discussion than a forum comment. Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like boxers moving on a ring and casually throwing punches. Long time Vim and Emacs users "get it", even though often don't follow true - some things never become gratifying instincts. Sometimes, even the opposite forms - redundant muscle memories.

Emacs is just old. Its foundations (as in the general design) are truly fantastic. I still don't understand how the heck not a single other editor over so many years has even considered replicating ideas like indirect buffers. That alone is a truly brilliant idea, and there are so many more.

Performance is atrocious today. At some point, a couple of decades ago, it might have been considered superb, but some may still remember "8 megabytes and constantly swapping". Emacs can be slow, yet its keyboard latency is still better compared to some other, more modern tools.

I'm not disagreeing with you, Emacs can be so damn annoying, and yet paradoxically remain enormously useful. Sadly (or otherwise), there's still no meaningful alternative to it, nothing even comes close. Lem has a promising story, but I remain skeptical. I think Emacs gets core C improvements sooner than Lem reaches meaningful, practical parity, although I might be wildly wrong in my prediction simply because I don't understand the scale of entanglement of the C-written core of Emacs, yet surely it's probably easier than porting the gigantic body of Elisp in existence to work in Lem.

I can't really comment on RMS' software developer skills - I have never directly reviewed his code. Perhaps, in modern times he'd be considered a "no hire", because being a software developer today requires a little bit more than just being a brilliant code writer.

I know that. Bumping GHC can still be relatively painful. Some language stacks are meaningfully easier on dependencies (not you Python), but can give you some other headaches (yes, you Python, damn you). Every PL in one way or another has some warts and ugly parts.

It seems the job of a senior software engineer these days is to make fun of programming languages on HN pointing out their flaws, while simultaneously keeping an eye, waiting on agents doing "thinking".

Oh wow, Haskell to Python. Interesting. They must have really wanted to preserve cascaded dependency headaches.

___

Please don't let your kernel panic, I'm being sarcastic. You never know the level of emotional attachment some HN people have to their tooling...

Lol, how are you so smart and figured just everything out, so already? I'd be so bored to ever touch the keyboard again. Bless Turing I'm so stupid and simple and keep trying different things just to see how they differ.

Emacs is not an editor. It's a Lisp-powered text orchestrator. It allows you to read, write, ocr, encrypt, decrypt, compile, debug, profile, browse, rss, email, calendar, track, journal, publish, tangle, run, query, spawn, multiplex, ssh, edit, diff, merge, blame, rebase, stage, review, chat, note, link, roll, play, run, preview, transcode, transcript, evaluate, redefine, introspect and rebuild anything in your computational vicinity - local and remote machines.

they are doing various changes (and control)

OMG. Don't let me even start here. Corporate IT cultures sometimes are so exhaustingly cretinous. With straight faces they'd perform "security theatre" that has nothing to do with security, but is still just so infuriatingly time-consuming and ignorant on even most basic things. Honestly, I am so thankful to Emacs for cultivating a hacker's mindset in me, otherwise I'd be so freaking burned out all the time if I didn't know how to bypass most of the nonsense they enforce on everyone. I even asked my IT guy once: "I don't get it, don't they realize that devs are just gonna play along with this bullshit maybe a couple of times and then they'll just fucking script a workaround? I for sure will...", and he was like: "I know, it is so stupid, but hey, I don't make these decisions here..."

What a nightmare. The day anyone tells me not to use a specific editor regardless of what it is, I'd be opening their suggested one to type my resignation letter. And not because I love Emacs, Vim or whatever.

I mean I'd understand enforcing using specific tools while pair-programming, mentoring, etc., but not allowing a software engineer to use whatever editor they are most comfortable using at all is not even dystopian, it's simply imbecilic. How are they supposed to not just "perform" but to get any shit done at all? It's equivalent of hiring a secretary and asking them to type everything in Hebrew (a language they have zero awareness of), using Dvorak (a layout they've never tried) and then complaining that their typing speed is undesirable.

How the fuck do these people even get to managerial positions? How in the world are these kinds of companies and company cultures not bankrupted themselves out of existence?

I feel you're now contradicting your own statements now. You said: "[maybe] Lisp is just another Blub", but when pointed out that Lisp (and Lispers) is evolving, you're saying "pg clearly meant [the other Lisp]"...

Of course we're not talking about "parenthesis". Clojure even added square brackets for arguments and destructuring, it's not about the syntax, I agree on that.