I don't owe you an explanation why I do it, why write anything at all. Why HN. I'll say it anyway. I do it because I still recognize people here. Living, dreaming, learning, fighting, hating, daring, loving people. I don't get paid for it, I don't seek recognition, I am not trying to build a name. I share my opinions because nothing is more important for our species than storytelling. And we need to share stories, listen to them, re-live them, learn from them. That's why many of us would go to watch Nolan's rendition of a 2700-year-old story. Even if we don't like the movie already.

And then someone like you comes, shits all over your charming writing, compelled to do it just because they see a word they don't like. Well, honestly, fuck you. Yeah, not nice, but I'd rather be kind and tell you the truth. You wouldn't be saying the shit you replied to me with to my face. Not because I have muscles, or am intimidating, or weak and miserable, no. But because you're definitely not a jerk, or an idiot. I wouldn't have to spend hours wasting on your ass for no good fucking reason. Seriously, I am a solo father with two kids, it's fucking 1:30AM and I'm having to deal with this shit, because writing for me is still fucking hard. English is beautiful, but hard. Come on, kid, think sometimes. For the sake of fellow humans.

Programmers write programs. That's the definition of the job. Any personal tweaks - scripts, snippets, extensions, packages, configs (for VSCode, IntelliJ, Vim and yes Emacs too) are also programs. Saying: "I don't want to maintain my programs" sounds to me like saying: "I don't want to be a programmer". It doesn't matter what I use - Emacs, Sublime or Macromedia Dreamweaver - configuring and maintaining it is not "kind of a job", "part of my job", or "someone else's job". That is my job as a programmer. Period. End of discussion.

Why the fuck you keep pouring your own made up shit from one pitcher into another, thinking it's about to turn into gold, is beyond me. And somehow I'm the dude that should "relax". Well, sure, let me then apologize for my inability to explain to you something that a six year old would get off the bat.

I can concur with that thought direction. We used to pair and group-program on my team, we have a "Zoom office". Now it has become "let me take this ticket and feed it to Claude, you try the same thing with Copilot, and then we compare the results", or "I'd make a PR with my clunker, you use yours to review it". This shit honestly feels almost pointless. The pair-programming is absolutely dead. Who wants to watch me run several agents, trying to fix multiple things in different work-trees, while I'm juggling them around and fixing inconsistencies in my agents.md?

I've been pushing the idea of building a self-governing, fully autonomous cloud pipelines so we'd stop playing "stupid tokenomy" games, and it seems my management is just quietly trying to "keep it down", because I think there's a simple understanding - the moment that shit proves airworthy and actually can fly, a bunch of them are guaranteed to lose their cushy seats.

Emacs-effect. Use it long enough and everything becomes "one big programmable surface". I've been in that modus operandi for years. Emacs is my "control room", I don't necessarily do everything in Emacs, but for sure it converges all into it - everything flows through Emacs. I control my WM directly from the REPL inside Emacs. I can grab a content from a tab in my browser - I have access to my browser history, and all the tabs, I can switch to any tab, close and re-order them. I can grab a text selection on the page, I can extract entire readable corpus of an article while ignoring all the irrelevant fluff - banners, ads, buttons, etc. It works even for js-rendered content (React, et al.). I play all videos controlling them directly from Emacs - even though the video itself is playing outside, in mpv. I still can pause, change volume, fast forward, speed-up, extract transcript, etc. All without leaving Emacs. That's pretty useful when taking notes. I can grab any text I see on the screen. Even if it's in Slack.app. Why, If I can read it, there's no reason why Emacs shouldn't be able to. I can grab any region on my screen with Flameshot, it goes through Emacs, runs tesseract and OCRs the text out of it. Useful when someone's screen sharing in Zoom. This was all possible before LLMs. Now, LLMs running in Emacs can do some crazy, wild stuff.

I just disagree with why Emacs heavy users are often "blamed" to be obsessed with their tools "needlessly". What does it even mean to desire "as little maintenance as possible"? Okay, let's say I don't use Emacs (which is like I dunno over 90% of existing programmers in the world). What, I won't be writing bash scripts for my work? Okay, maybe I really hate Bash. Python then? Lua? Perl? What the hell are we even talking about? Of course, a programmer will do these things. Every programmer does. There's not a single case where a programmer doesn't tweak, re-tweak, personalize, improve, readjust their tooling, their scripts, browser extensions, the set of apps they use. Why is it Emacs and Vim considered a "perpetual maintenance", and I dunno, VSCode is "it just works™"? That's just not true. If I didn't use Emacs, I'd be inevitably re-inventing some workflow automation in some different way. Or what, bash-scripts ain't no software?

What I meant is that viewing Emacs merely as a means to achieve a singular goal and to extract specific value (e.g. "I've heard Magit is nice") is shortsighted - approaching it as a strategic, long-term investment yields far greater returns. I'm not preaching for absolutely every programmer to use it.

Come on, now tell me how I think of everyone who doesn't approve my web-browser tweaking habits as "catastrophic failures"...

Ownership can have different forms. Slack.app that doesn't let me easily extract code snippets from a thread - owns me. Jira that forces me to use their imbecilic, quirky wysiwyg owns me. Note taking app that keeps the data in their db and not my files - ain't my friend. The friction is the ownership. When extraction 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 in Slack/Jira/Dropbox/Evernote/Notion/etc. 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.

Plain text, local files, standard formats - they don't fight you on extraction because there's nothing to protect. That's why investing in FOSS tools is almost always paying for your own liberation rather than your own imprisonment. Even when there isn't feature parity, even when the FOSS tool doesn't have a "polished UI" and it's "maintained by a teenager in Nebraska" - still a better choice.

I honestly can't even relate to what that even means. I'm a programmer - my everyday job is all about changing the behavior of computer systems - local, remote, cloud, embedded, etc. Requirements change, scope fluctuates, problem space evolves - grows and shrinks, accretion is unavoidable. I need to routinely move between language stacks, different data types, formats, CLI and web tools, protocols, paradigms, OSS and proprietary apps.

That means I have to constantly adapt, my control plane has to keep up with the flux. Automation is key - you must develop a mentality for that - every little annoyance can be and shall be automated. That is an endless, non-stop transformation of my workflow - continuous maintenance of my tooling. But that is not some toilsome, reactive maintenance.

Thinking that you're a programmer that doesn't want to constantly build software for your own sake is a delusion - it's like a cook that hopes to turn on the stove only in the restaurant, but won't touch a knife at home.

Emacs is the cook's home kitchen. I'd say there are two kinds of maintenance: reactive (fixing breakage, keeping up with churn) versus generative (shaping tools to match your evolving understanding). Programmers instinctively dislike the first and should be drawn to the second. Emacs is almost uniquely suited to generative maintenance because the tool and the work share the same substrate.

I get your complaint about Emacs specifically, it's a common: "too much work to set up", which usually means: "I don't want to invest before I get value", which honestly is not wise, strategic thinking. Treating Emacs as the universal tool for minimizing total maintenance burden over a career, over a lifetime is.

Fun anecdote - I once needed to sort some nested items in a big yaml file. After spending three minutes trying to understand sort-regexp-fields (or some other function), I cheated - I ran org-mode, and then org-sort and then went back to yaml-mode. So stupid, yet so brilliant. Why the heck would I ever want to use "first-class IDE" or "intuitive, plebeian editor" if Emacs has anything I could possibly imagine? Right at my fingertips.

___

¹ https://github.com/agzam/org-edit-indirect.el

² https://github.com/thanhvg/emacs-hnreader/

³ https://github.com/thanhvg/emacs-reddigg

⁴ https://github.com/agzam/slacko.el

⁵ https://github.com/agzam/go-jira.el

⁶ https://github.com/agzam/wiktionary-bro.el

Whoa, it seems you're using LLM to generate Clojure code like you'd do it with any other "static" PL. Give it a live REPL - it works wondrously.

Nope. Not with Lisps. I've been using LLMs with Clojure/Clojurescript, Elisp and Fennel - for my personal stuff. And Python, Java, JS/TS, Go for work. LLMs are surprisingly good with Lisps, perhaps precisely because there's less fragmentation. There is so much variability with say Python for a given task, because the training set is enormous. But how many ways there exist to do the same thing in Clojure? Python/Java/TS's enormous training set is almost a liability for quality - the model has seen every beginner tutorial, every legacy pattern, every conflicting style guide. With Clojure it's more like the model learned from a curated corpus by default. Lisps have nearly zero syntactic noise - the AST is the source. This means an LLM doesn't need to learn parsing heuristics; structure is always explicit. That likely makes correct generation easier even with less data.

The irony is that Lisp looks cryptic to newcomers precisely because there's almost zero syntactic sugar hiding the structure. Once you adjust, you realize the "weird syntax" is actually the absence of magic - it's the parse tree, exposed directly. Alas, people prefer sugar flavored lies instead of "inconvenient" truth. I was pretty much the same - wasted years of my life, circling around shit that was all about "magic". At some point, your mind just can't take it anymore - it wants "plain & stupid". Because when shit just works - it doesn't feel that stupid anymore.

- Functional (its primary identity)

- Data-oriented (how you model your domain)/data-driven(how you control behaivor)

- Polymorphic/interface-driven (protocols, multimethods)

- Logic-style (via core.logic) - mostly unused

- Reactive/event-driven/actor-like concurrency (core.async, manifold)

- There's another paradigm vector (Spec/Malli), but it frankly has the gap in the terminology landscape. It's neither Dependent Typing, nor Gradual; not quite Contract-based Design; not Refinement Types (typically a static concept); calling it Schema Validation really undersells it - implies just input checking. It does something genuinely novel in combination. There isn't a single established term to capture all of that.

Where the language resists:

- Classical OOP with mutable stateful objects - you can do it via Java interop or careful use of atoms+records, but the language actively nudges you away. It won't feel natural and you'll be fighting the grain.

- Imperative/procedural style - possible, but again, why?

That is only accurate if OOP means "inheritance-based class hierarchies with mutable state" - which is one narrow definition of it. Clojure has solid OOP support, just not in the class-hierarchy-first sense.

Now imagine the same principle works with backend services, e.g. we've enabled nrepl endpoint in our staging k8s service, we can modify the behavior dynamically, like adding a new route, for that we'd just need to connect to the REPL, write something like `(POST "/v1/new-effing-route" request ...`, eval it and voila. We don't have to re-deploy, recompile, even save that code - it would just work, like magic.

Now imagine giving this ability to an LLM. It won't have to guess, it won't have to go into write/compile/run/restore-the-state/try loop - it knows what's available, what can affect the behavior of the system, etc. It works surprisingly well and saves tons of time and tokens. Kids who have not tried that, have zero idea how great that is.