Rendered at 22:03:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
codazoda 3 minutes ago [-]
Lots of interesting takes that I think I disagree with here, although I mostly write Markdown rather than read of:
> they’re hamstrung by the terminal itself, which is almost always monospaced and thus fatiguing to read.
I recently re-built Blue, a minimalist text editor inspired by the Turbo Pascal and Turbo Basic editors of the late 1990's. It uses a fixed width font, because I prefer it.
I've absolutely engaged in making personal software [0] thanks to the age of LLMs.
But to be honest, my time using Emacs didn't teach me to "build personal software". My Emacs set up was extremely brittle, and it was a nightmare when I tried to use it across Windows & macOS. My university project was written using an unholy combination of org-mode & some workflow to create a beautiful LaTeX file, and I couldn't tell you how to recompile it (if I were to try, I'd probably get an LLM to literally translate it to LaTeX).
I want my life to have as little maintenance as possible, and making my own software for everything isn't always compatible with that.
Have had the same emacs setup on linux, windows and macos for 15 years. Honestly, it's the best thing in my computing life.
3 hours ago [-]
TacticalCoder 59 minutes ago [-]
> I want my life to have as little maintenance as possible, and making my own software for everything isn't always compatible with that.
So LLMs are good enough to make personal software, but not good enough to maintain them?
MrJohz 55 minutes ago [-]
It's usually easier to build something that maintain it for extended periods of time, particularly if that maintenance requires adding new features.
d0mine 39 minutes ago [-]
“Those who say they lack time to build tools are precisely the ones who cannot afford not to.”
SoftTalker 4 hours ago [-]
"Personal Software" i.e. programs that one writes for oneself, was the original vision of home computing back in the 1960s. The PC wasn't really anticipated, but the thought was that everyone would have a computer terminal at home, and write programs to do whatever was needed. It was imagined that programming would become easy enough that anyone could learn to do it. We're not there yet but with LLMs we're getting closer.
edbaskerville 3 hours ago [-]
The road not (yet?) taken is the full flowering of the HyperCards, the Visual Basics, the Macromind Directors and Flashes...
That is, the idea that a non-expert might create interesting software in an authoring environment with good, well-thought-out building blocks and easy-to-grasp metaphors, shorn of layers of accidental or over-engineered complexity.
In this vision software still requires careful logical thinking, but it makes it much less cumbersome to translate that thinking into running code, with no tooling and build system nightmares.
Instead, we've invented such powerful models that they can regurgitate and recombine complex incantations on our behalf. The complexity is still there, though, and it's still inscrutable to non-experts.
But maybe they can help us eliminate some of it?
I think that path is still possible, and it may even nicely complement the LLM world, where LLMs help generate software that individual humans can still easily comprehend and manually modify.
jorl17 2 hours ago [-]
I have told this to many friends who scoff at me, but using a computer is very clearly going to also mean "having the computer create programs for you". We won't even think or know about it.
To me, it isn't a matter of if, and the matter of when is also very clearly in "at most 10 years, probably much, much earlier", given that I have relatives already doing this without knowing how to code.
This is a future of computing I am absolutely in love with, and is so incredibly empowering!
munk-a 3 hours ago [-]
LLMs are great for problem exploration. Especially with the decline of Google I think we're at a point where it's less difficult to get an LLM to spit out something that'll accomplish a task sorta compared to actually finding that on the internet. But if the task is going to be repeated or modified then I think LLMs are at a permanent disadvantage to prebuilt software. Even if that prebuilt software is just someone else running an LLM and then passing the output through acceptance testing most people just don't want the headache of debugging weird edge cases and the novelty of "I'm a developer too!" wears off pretty quickly.
I'm excited that the weird grey-zone of excel sheets with business critical logic is likely going to disappear as LLMs slowly make the logic driving those too complex to be comprehended and managed and those get foisted off onto actual engineering resources. It'll be painful but probably for the best... but for actual tools people need to use day-to-day I think the assurance that the tool will work has a lot more value than the AI hype has comprehended.
TFNA 3 hours ago [-]
> Especially with the decline of Google
Oddly enough, Google’s LLM is the only one that has been answering my questions well on a research project these last weeks. I’m getting information from scanned text files that exist on the internet but were never adequately OCRed by other LLM companies (i.e. both OCRed at all, and moreover OCRed as the specific language in question that picks up all the diacritics). Google search results may be disappointing and polluted for years, but the company is still offering a useful product in another tab of its interface.
QuercusMax 2 hours ago [-]
I've found Gemini to be very helpful in figuring out all the fiddly linux problems that used to require reading endless forum posts and digging through docs.
SkyEyedGreyWyrm 2 hours ago [-]
My fears with the situation you are describing is that we end up without a common file format, if everyone has a propietary app and/or file system then that makes transition or collaboration a pain.
We probably won't end there due to how lazy most of us are, but it's certainly something to consider
zrail 1 hours ago [-]
I feel like I'm way more cynical than most people around here about LLMs but if we accept the parent comment's framing, why can't we just use an LLM to write a throw-away converter to whatever new format is necessary? Yes of course it'll probably be lossy occasionally but the question will be, is that ok for the user doing the conversion?
ex-aws-dude 2 hours ago [-]
That's going to be huge thing in the future I think
Everyone having their own hyperspecific apps or even different UIs/visualization in the same app
The whole idea of an application becomes a much more fluid thing
If your app is built with a dynamic language why not let users re-write the code themself and add whole new features
lobf 3 hours ago [-]
It’s exactly what I use LLMs for as a non-computer professional.
ErroneousBosh 3 hours ago [-]
> It was imagined that programming would become easy enough that anyone could learn to do it.
Arguably LLMs take us further away from that than we've ever been. All they do is automate copying and pasting in shit from StackOverflow.
We were closer to everyone being able to learn how to program computers in the mid-80s when everyone had one and they started up with a BASIC prompt.
chickensong 37 minutes ago [-]
Ah yes, the 80s, when everyone had a computer.
ErroneousBosh 26 minutes ago [-]
Well, yeah. The home computer revolution.
Literally everyone had a ZX Spectrum, or Commodore 64, or a BBC Micro if their parents were rich and thought that having the same as they had at school was a good idea.
chickensong 19 minutes ago [-]
If you change "literally everyone" to "a minority" we can agree.
morpheuskafka 3 hours ago [-]
This article hints at what I feel is one of the not-yet-realized transformations that LLM coding brings: can we finally drop Electron/React Native and just have LLMs automate the work of transforming Figma/wireframes and behavior specs into truly native apps for each platform?
For CRUD apps, the API spec and UI mockups -- or even a photo of how it looks on the already coded platform -- would go a long way. That's exactly the kind of well defined task work LLMs do well with. It should be possible to automate a lot of the equivalence testing too.
Is there still an excuse for "maybe we'll add Android someday" or "not enough Mac/Linux users"? And is there still a justification for not building those less-used flows like password reset into the iOS app instead of throwing up random WebViews?
For those apps that do have non-trivial logic on device, LLMs have shown a lot of promise at rewriting to cross-compiling-is-easy languages like Go or Rust.
tptacek 3 hours ago [-]
Yes. You can do that. It works right now. It works really well.
My original spicy take is: why learn SwiftUI at all at this point? It's a skill that, for most tasks, falls into the same kind of bucket as "learning Microsoft Word really, really well". I appreciate people who take the time to do that, but the outcomes are within millimeters of each other whether or not we do that.
I don't think that's true of programming generally. But I think there are languages now where the rationale in specializing in them has gotten, hrm, more complicated.
simoesd 8 hours ago [-]
I know the article is mostly about making stand-alone software, but this type of thing is why one of the things I value most when looking workflow tools I will be using heavily is extensibility. I can try put someone's neovim plugin for a second, figure out if it's something I actually need, and if so make my own personal version that matches my mental model perfectly, adds all the dumb little bells I want, and removes all the useful features I don't personally care about. Plus I no longer need to worry nearly as much about supply chain issues.
Over the years I've replaced 90% of the plugins I used when I started. Plus I get a nice outlet from any pesky NIH symptoms.
disinterred 4 hours ago [-]
I'm the same.
In all honesty, when you start up emacs for the first time with a blank config, it looks terrible. But then you start building it up with plugins and adding code to support your own quirky workflows and slowly it becomes too powerful in your life to ignore. I have not been able to drop it for 13 straight years. With AI taking over the development experience, emacs and neovim have only become even better, because now you can get AI to bake your custom workflows into the config for you.
Emacs/neovim should be the gold standard for all workflow tools.
phyzix5761 4 hours ago [-]
I did the same. I started with Doom Emacs and then a year later decided to start from scratch and build the computing environment I wanted. But I think the experience of Doom showed me what was possible, what I liked, and what I really had no need for.
I make small config changes every day and its super fun to use my computer this way. I wish everything was configurable like Emacs.
tptacek 3 hours ago [-]
It is! That's the post!
applfanboysbgon 4 hours ago [-]
I feel as though the author really missed an opportunity here: "The Emacsulation of Software"
kettlez 2 hours ago [-]
Enjoyable article. I've had the same feeling about native software becoming more accessible with the help of llms. However, I tried the app and opened a large-ish markdown file and immediately had scroll hangs and then the app crashed. Making a small proof of concept is easy, but performance and reliability are still hard.
edit: typo
bananamogul 31 minutes ago [-]
"the terminal itself, which is almost always monospaced and thus fatiguing to read"
It is? Why? I read monospaced text all day long. I don't find it fatiguing in the least. In fact, I think I might prefer it to non-monospaced text.
nemoniac 27 minutes ago [-]
Interesting article.
When my Emacs opens a markdown file it immediately converts it into OrgMode format. I find that more readable, more navigable and more editable.
Now I'll have to go and meditate about Emacsification.
iLemming 5 minutes ago [-]
I know, right? Org-mode is soooo much more practical. imenu works great, sparse-trees are awesome, you can edit pretty much any part in an indirect buffer and all. These days I try to consume anything that can be fit into an outline, in org-mode - hackernews, reddit, slack, jira boards and tickets, wiktionary entries, etc.
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.
noelwelsh 2 hours ago [-]
Ok, not the article I thought it was going to be. In fact it's the complete opposite of what Emacs means to me. For me, the point of Emacs is that I use one program to do everything. Why would I want a special bit of software just to view Markdown? I can view it in Emacs, and then it works with everything else I do. Developing lots of custom applications, AI assisted or not, is not replacing how I use Emacs.
tptacek 1 hours ago [-]
The point of the article is that the whole gestalt of what you do on a computer is now one big programmable surface, and in that regard everything feels a lot more like Emacs.
It's not "about" Emacs, it's more about the vibe of personalized software in 2026 to someone who does a lot of Emacs stuff.
skydhash 1 hours ago [-]
Not really the same. Emacs focus a lot on compatibility and common modules (even if there may be some different takes on those common things). So you got big systems like helm, consul, ivy, company,… and the. everyone building on top.
Another thing is configuration (which also ties to the previous statement). You have to be able to split the idea of the program (what it aims to do) and your personal preferences. Emacs make that easy by having a framework for user preferences. That makes for an extendable program.
The closest, but not as user friendly is unix and suckless philosophy combined. Small programs, easy to understand, configure, and extend.
jr_isidore 59 minutes ago [-]
OP is trying to say Home Depot let normies do their own small repairs, and you're protesting saying "No, no, that's not how we pros do it."
orbital-decay 1 hours ago [-]
The article provides an analogy, it doesn't tell you to do anything with Emacs in particular.
Besides being an everything app for you, Emacs is an (unconventional) operating system with weak boundaries between user apps. It makes it easy to modify anything, write new things, or combine two existing ones with very little code, something that e.g. Microsoft could have only dreamed of in Office with its awkward embedding that barely worked. Emacs is one the few survivors of the idea that users should program what they need, which was popular during the personal computing revolution in the 80's. Two others are spreadsheets and BASIC.
Programming turned out to be too complex for the untrained users to handle, but AI makes the idea of custom one-off apps or weird hybrids pretty damn close, that is true in practice. I see a lot of people that vibe code their own little things to get things done. That's precisely what BASIC (often shipped in the stock ROM!) was supposed to be used for.
jrm4 55 minutes ago [-]
Same thing, actually, I think.
I think that "the number of programs" you're suggesting is arbitrary. It's kind of like calling an operating system one thing, when it's a lot of things. You can "count" the things different ways.
The bigger takeaway is "making your own programming things."
aledem 3 hours ago [-]
I remember how just 5 years ago the majority of speakers were saying how absolutely everyone should learn computer programming. Already many years ago VBA was built to bridge the gap between engineers and other professions.
Well, the gap is completely closed now, everyone can do what has been talked about for decades: programming computers. And I suspect even markdown will become obsolete very soon, eliminating this very last remnant of what programming used to be.
ogogmad 3 hours ago [-]
Maybe it's a good idea for SWEs to consider using LLMs to train themselves into new careers -- just in case.
Most other "knowledge" professions -- by which I mean teaching, programming, some engineering, and the arts -- are even further along into obsolescence. That said, you can still use the knowledge gained in a knowledge profession to convert into a more hands-on profession. We might have a bit longer before humanoid robots destroy all hands-on job opportunities as well. Once that happens, every person will be equally poor and destitute.
iLemming 2 hours ago [-]
Ehmm, weird, I can't be the only one in the room. You guys didn't know about gfm and gfm-view Emacs modes?
TacticalCoder 60 minutes ago [-]
> Ehmm, weird, I can't be the only one in the room. You guys didn't know about gfm and gfm-view Emacs modes?
I'm using Emacs since last century and I've got 3 000+ lines of custom Elisp code I wrote (with maybe only a few hundred lines copy/pasta'ed from other configs).
I'm always using a recent Emacs compiled from source and now with LSP, org-mode, Magit, tree-sitter, ivy/avy/counsel/swiper with ripgrep (thanks burntsushi) integration etc.
I had zero frigging idea what gfm and gfm-view for Emacs were.
But I'll look into it now!
malicka 3 hours ago [-]
Speaking of which, Emacs’es markdown-mode is pretty good. :^)
tptacek 3 hours ago [-]
Emacs is an editor! God help you if you do something to my computer where when I click on a Markdown file something changes in my Emacs window setup.
dang 2 hours ago [-]
This is so exactly right and I've been saying it to whoever will put up with me...(and now am embarrassed I have no link to show for it.)
Software production is so easy now that everything is a .emacs file: meaning, each individual has their own entirely personal, endlessly customizable software cocoon. As the article says, it's "easier to build your own solution than to install an existing one" - or to learn an existing one.
A similar analogy, not by concidence, is Lisp in general. The classic knock against it—one I never agreed with but used to hear all the time—is that Lisp with its macros is so malleable that every programmer ends up turning it into their own private language which no one else can read.
Tangential to that was Mark Tarver's 2007 piece "The Bipolar Lisp Programmer" which had much discussion over the years (https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%2...). He wrote about the "brilliant bipolar mind" (BBM) - I won't get into how he introduces that or whether it's fair or not, but it's interesting how mental illness comes up, given how "AI psychosis", in both ironic and unironic variants, is so frequently referred to these days.
The phrase 'throw-away design' is absolutely made for the BBM and it comes from the Lisp community. Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp [...] No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine. This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something.
Sounds pretty 2026, no? He goes on:
The C/C++ approach is quite different. It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere. And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one).
The flip side of all this is that when production is so easy, the bottleneck becomes consumption, and sharing turns into an unsolved problem. This is why the Emacs analogy is so good. A .emacs file is as personal as a fingerprint. You might copy snippets into yours, but why would you ever use another person's? (other than as a way to get started as a noob). You just make your own.
The more customized these cocoons get, the harder they are for anybody else to understand—or to want to. This distinction is important. It isn't just that somebody else's cocoon has too high a cognitive cost to bother learning, when you can just generate you own. It's also uncomfortable, like wearing someone else's clothes. It's as if the sense of smell gets involved.
Rather than ai psychosis, we could call this ai solipsism.
In software it's fascinating how configuration management (that boringest of all phrases) is becoming the hard part. How do you share and version the source? What even is the source? Is it the prompts? That's where the OP heads at the end: "share it somewhere — or, better yet, just a screenshot and the prompts you used to make it." But when I floated a couple trial balloons about whether we might use this for Show HN—i.e., don't just share the code you generated, because that's not the source anymore; instead, share the prompts—we got a lot of pushback from knowledgeable people (summarized here: https://news.ycombinator.com/item?id=47213630).
These dynamics must be what's behind the pipe-bursting pressure that Github has been under. What a Github successor might look like is far from clear, but as a clever friend of mine points out, it's likely that there will have to be one. Projects and startups along these lines are appearing now, but we seem to be in the horseless carriage phase still.
Even more importantly, what happens to teamwork? To put it in Tarver's terms, if we are all a BBM now—or rather, we all have armies of cheap BBMs, permanently locked in the manic phase, waiting at all hours to generate things for us-and-only-us—how do we work together? How do cocoons communicate, interoperate? How does a team of ai solipsists function? It sounds oxymoronic.
My sense is that a lot of software teams, startups and so on, who have been on the cutting edge of AI-driven / agentic development, are currently grappling with this, not (only) philosophically but in very practical ways. e.g. how does my generated code compose with your generated code. With these issues, we end up giving back some of the productivity gains of generated code in the first place, and it makes sense that these effects show up over time, as the systems being built this way grow in complexity and the maintenance/development tradeoff becomes a thing.
No one seems to talk about it publicly. It makes sense that no one wants to be the first to stop clapping and sit back down during the endless standing ovation, but it's too bad that we can't (yet) talk seriously about the downside that accompanies this upside, as it does any upside. (I mean on real software teams building real systems, not AI/society thought pieces.)
[editing - bear with me...]
jr_isidore 14 minutes ago [-]
Tarver's piece was new to me, and fun, and spot on. Yes, LLMs bring the emacs cruft heap to the masses. A throwaway culture on disk is a lot less worrisome than one on soil.
RickS 3 hours ago [-]
I agree, experience this, love it, etc.
The "0% product hunt, 100% show and tell" bit is one of the benefits of an ecosystem with painfully high upfront entry costs.
Does anyone know of an active forum of any kind (discord, reddit, phpbb, mailing list, whatever) for people who are building personal applications like this for love of the game, which takes hardline stances about desirable vs undesirable motives and behaviors, and enforces high entry/participation costs in exchange for unusually low quantities of transient grifters and self-interested status seeking by day-old accounts?
argee 2 hours ago [-]
If you’re building for the "love of the game", aren’t you unlikely to post an artifact that is produced towards the end of your project and targeted towards a publication (e.g. hacker news)? I recall Mitchell Hashimoto was saying he used to browse GitHub as if it were a social media (which it is) - perhaps that’s your jam.
tuo-lei 3 hours ago [-]
i've made maybe 20 personal LLM tools this year. 3 survived past the first week. not because the rest weren't useful, just wasn't willing to debug them when something broke.
alex_smart 3 hours ago [-]
Which is where the "emacsification" analogy breaks for me.
The reason people who like emacs write their one-off program in emacs is that it is an extraordinarily introspectable and debuggable programming environment. There is no "code, compile, run" loop - you just write code against the live running environment. Devoid of that fast feedback loop, writing code just isn't as much fun.
jr_isidore 2 hours ago [-]
Well taken, but for MANY years, I copied and pasted elisp snippets off stackoverflow without understanding any of it. And to this day, there as many xkcd-style "space heaters" as there are emacs users. OP's point stands that LLMs make possible a new generation of quicker, dirtier hacks destined for the cruft heap.
tptacek 3 hours ago [-]
What were the three?
ctrl4 3 hours ago [-]
Not OP:
- One shotted script that I schedule through cron that sends me a message when a new one piece manga chapter releases.
- Also a simple script that moves my cursor one pixel every 30 seconds. Cannot disclose why I need this.
j2kun 4 hours ago [-]
> You want a good Markdown viewer more than you think you do.
> monospaced and thus fatiguing to read.
Monospaced text is fine. I don't see how people who read code (and code comments) all day care that strongly about this. Plaintext is king
tptacek 4 hours ago [-]
There's a reason we're not reading monospaced here, and a reason we do read monospaced code.
But the beauty of this moment is that if you want a really good SwiftUI monospaced Markdown reader, you can have it before dinner. This is exactly what I'm talking about. You have an idiosyncratic personal preference, and it's now reasonable to expect software to shrink-wrap around that preference.
j2kun 59 minutes ago [-]
Generally I just don't appreciate when someone jumps from "I care about this" to "everyone cares about this for obvious reasons." Focus on what something means to you, and being sincere about it. But that is just my advice for writing, take it or leave it.
Also, are browser text area inputs monospaced by default for everyone? Or did I configure that for myself long ago and forget? If it's not just me, maybe the "reasons" you're alluding to are not so obvious. Anyway, I have no trouble at all reading the long comments I type into text areas.
And more power to people for embracing agency :)
applfanboysbgon 3 hours ago [-]
> a reason we're not reading monospaced here
Legacy decisions as a remnant from a time when taking more space on paper cost pages and therefore resources, remaining as a default from centuries of inertia in how text is printed?
tptacek 3 hours ago [-]
No, prose set in monospace is harder to read. The "legacy" is monospace! We went way out of our way to to get proportional typesetting working.
But seriously: you do you. There are people who code in proportional typefaces and they're as baffling to me as you are right now. Let a thousand Markdown viewers bloom.
applfanboysbgon 3 hours ago [-]
> The "legacy" is monospace! We went way out of our way to to get proportional typesetting working.
The legacy is proportional, at least in Latin script and its ancestors. Handwriting was proportional, of course, and so was Gutenberg's printing press. Books and newspapers have virtually always been printed in proportional type.
In Chinese and Japanese, monospace is legacy in both handwriting and print... and also still universally used today. All Chinese and Japanese text is monospaced by default. Billions of people are getting by just fine reading monospaced prose.
I don't really know where this conception that monospaced is somehow objectively harder to read is coming from. Actually, this is the first I've ever heard of the complaint. I can't help but wonder if you've been subjected to some very bad monospaced fonts in prose or something.
mrob 3 hours ago [-]
Monospace text is objectively less dense, which means you have to move your eyes more. Every eye movement is an opportunity for error. Monospace text only makes sense when seeing exact character counts matters (which it often does in computer code).
applfanboysbgon 3 hours ago [-]
One could argue that less density, as well as standardised widths, significantly reduces opportunity for error compared to cluttered text that is constantly varying how it is displayed. Perhaps moving your eyes more increases opportunity for error by 10% but easier-to-parse characters decreases the opportunity for error by 20%?
richiebful1 2 hours ago [-]
There's limited research on readability of monospaced font. But this study suggests monospace is weakly more readable than variable-width font:
Turn off syntax highlighting for your code, translate it to COBOL, and pass it through a formatter that converts it to continuous word-wrapped text. Then we’ll talk again.
j2kun 2 hours ago [-]
I have written multiple books entirely in LaTeX edited with neovim. So... your point is not taken.
layer8 1 hours ago [-]
Authoring is different from reading.
And why did you author them in LaTeX if you think reading in monospace plaintext is fine for everyone?
tptacek 2 hours ago [-]
I'm a fan of your writing, all the more because you've somehow managed to do all of it in monospace. :)
kanbankaren 3 hours ago [-]
Surprised that Monaspace hasn't been mentioned below.
There is a real use case for a viewer if you have a lot of formulas. Yes you can read the raw latex but you go cross-eyed after a while. Maybe I am a softie though.
3 hours ago [-]
j2kun 2 hours ago [-]
I agree, but I don't think the author of this blog post is coming from that perspective, and markdown renderers of the sort described in the post tend to do pretty poorly with math typesetting.
il-b 3 hours ago [-]
The dislike of code per se is what drives these people to use agents in the first place.
jrm4 52 minutes ago [-]
Nothing personal but I hate this take with a passion, and I literally think it's representative of the worst attitude in computing because it's the literal opposite of software SHOULD BE.
The whole entire point of computers in their best light is changeable software, the whole point should be "let people read how they want to."
noctuid 1 hours ago [-]
Terrible analogy. Emacs has always had comparably fewer major options for packages compared to other tools, there is often an obvious option based on your needs, and it has never been my experience that people decide to just roll their own versions of everything. The author has clearly never used neovim or now pi. NPM packages in general would have also been a way better example.
tptacek 28 minutes ago [-]
Seriously, your idea here is maybe you can start an Emacs vs. vi fight in the comment threads?
noctuid 23 minutes ago [-]
No one mentioned vi, I like neovim just fine, and I'm using pi daily. Nice try though. My only point is that if you want to talk about rewriting everything yourself, NIH, churn, whatever you want to call it, Emacs is absolutely not a great example.
jr_isidore 44 minutes ago [-]
Are we reading the same article? OP is saying LLMs let normies tweak their personal workflows in the same way we emacs nerds had been doing for decades. Contrary to the old saw about it being an OS, Emacs is really just a shell but with lisp as its command language instead of unwieldy bash. Once Claude magicked an English to bash translator, raw shell has caught up to emacs in its ease of use.
noctuid 33 minutes ago [-]
The new thing where everyone just vibe codes their own versions of everything is not at all like personalizing Emacs.
Specifically the idea that people generally just ignore existing versions of packages and make their own has never been the case, especially compared to other editors (even VSCode).
> There are popular elisp packages lots of people use. But except for Magit, nerds are alarmingly apt to replace them with their own shinier versions (and then to show them off, transitioning to the spore-forming phase of the elisp lifecycle). Everything in Emacs is malleable.
> Until now, the Achilles heel of Emacs culture has been that, except for Magit, its packages tend to be wretched user experiences. Ugly, slow, and discoverable only after inflicting years of elisp cortical injuries on yourself.
I love this and I have a handful of tools like this that I built for myself (I had claude write me a TUI crossplane kcl function renderer, for example -- something whose total addressable audience in the world is probably 20 people).
"Content creation for an audience of one" is really the revolutionary change that is happening right now because of AI. Disposable apps, disposable books, disposable movies, disposable music. Things that are made for a single person, used once or a handful of times and then thrown away. The entire economic model of content creation and distribution is going to explode in the next 3 or 4 years, and very few people are prepared for it.
applfanboysbgon 4 hours ago [-]
Setting aside the fact that good content is more enjoyable than bad content, experiences are meant to be shared. Humans are a social species, and a very large part of media consumption goes beyond the actual consumption and into sharing that experience with other people. People build communities around the media they like, and even integrate their favorites as part of their identity, wearing branded clothes or cosplay, decorating their rooms with merch, setting wallpapers, and so many other ways to signal what they enjoy to others. "Content creation for one" rather misses how humans work. Heck, not only media but even tools are subject to this -- people legitimately make emacs or vi part of their personality.
> The entire economic model of content creation and distribution is going to explode in the next 3 or 4 years
I think this is also inherently self-contradictory. What's the point of distributing content made for one? This gets into the same fallacy that people engage in w.r.t. "applications for one" displacing software developers. Yes, LLMs can pump out buggy software that suits one person's needs, and it doesn't need to be reliable enough to deploy at scale. It serves real utility here, because there was a gap between "the value of such software" and "what software developers are willing to work for", which meant that this software wasn't being created because there wasn't economic value in it. But then, how does one suppose software that has no economic value is going to replace all the professional software developers who were being paid to produce software that has economic value? LLMs filled a gap software developers weren't being paid to do, but given that they were not paid to do it, their jobs are not contingent on the existence of this niche. It simply doesn't follow that being able to produce content with zero economic value, whether that's applications or content for one, will cause an 'explosion' in the existing economic models.
ElevenLathe 4 hours ago [-]
I'm with you on purpose-built disposable tools, but who wants to read a disposable book, or watch a disposable movie?
tptacek 3 hours ago [-]
Not me. I'm enthralled by what this moment promises for building software, but I'm yicked out the same way everyone else is by generative art.
dogleash 3 hours ago [-]
> Suddenly, I realized: a good Markdown viewer was a dumb thing to waste time looking for. It’s 2026. I can just have one extruded for me.
If this is the starting thought, I don't know how you wrap back around to publishing and advertising the generated code.
Either you create the best possible mac markdown viewer and should share it as that, orthogonal to any statement of AI use. Or you're just adding to the noise of tools available online. Where other people should ignore your work, and go slopcode their own markdown viewer.
tptacek 3 hours ago [-]
The post talks about this.
dawnakle 8 minutes ago [-]
[dead]
KaiShips 3 hours ago [-]
[flagged]
selectively 4 hours ago [-]
No, I don't. I don't want anything that has to do with John Gruber, ever.
> they’re hamstrung by the terminal itself, which is almost always monospaced and thus fatiguing to read.
I recently re-built Blue, a minimalist text editor inspired by the Turbo Pascal and Turbo Basic editors of the late 1990's. It uses a fixed width font, because I prefer it.
https://github.com/codazoda/blue
But to be honest, my time using Emacs didn't teach me to "build personal software". My Emacs set up was extremely brittle, and it was a nightmare when I tried to use it across Windows & macOS. My university project was written using an unholy combination of org-mode & some workflow to create a beautiful LaTeX file, and I couldn't tell you how to recompile it (if I were to try, I'd probably get an LLM to literally translate it to LaTeX).
I want my life to have as little maintenance as possible, and making my own software for everything isn't always compatible with that.
[0]: A rewrite of a NETFX application in Rust, simply because the 20 minute installation time irked me: https://github.com/bevan-philip/wlan-optimizer
So LLMs are good enough to make personal software, but not good enough to maintain them?
That is, the idea that a non-expert might create interesting software in an authoring environment with good, well-thought-out building blocks and easy-to-grasp metaphors, shorn of layers of accidental or over-engineered complexity.
In this vision software still requires careful logical thinking, but it makes it much less cumbersome to translate that thinking into running code, with no tooling and build system nightmares.
Instead, we've invented such powerful models that they can regurgitate and recombine complex incantations on our behalf. The complexity is still there, though, and it's still inscrutable to non-experts.
But maybe they can help us eliminate some of it?
I think that path is still possible, and it may even nicely complement the LLM world, where LLMs help generate software that individual humans can still easily comprehend and manually modify.
To me, it isn't a matter of if, and the matter of when is also very clearly in "at most 10 years, probably much, much earlier", given that I have relatives already doing this without knowing how to code.
This is a future of computing I am absolutely in love with, and is so incredibly empowering!
I'm excited that the weird grey-zone of excel sheets with business critical logic is likely going to disappear as LLMs slowly make the logic driving those too complex to be comprehended and managed and those get foisted off onto actual engineering resources. It'll be painful but probably for the best... but for actual tools people need to use day-to-day I think the assurance that the tool will work has a lot more value than the AI hype has comprehended.
Oddly enough, Google’s LLM is the only one that has been answering my questions well on a research project these last weeks. I’m getting information from scanned text files that exist on the internet but were never adequately OCRed by other LLM companies (i.e. both OCRed at all, and moreover OCRed as the specific language in question that picks up all the diacritics). Google search results may be disappointing and polluted for years, but the company is still offering a useful product in another tab of its interface.
We probably won't end there due to how lazy most of us are, but it's certainly something to consider
Everyone having their own hyperspecific apps or even different UIs/visualization in the same app
The whole idea of an application becomes a much more fluid thing
If your app is built with a dynamic language why not let users re-write the code themself and add whole new features
Arguably LLMs take us further away from that than we've ever been. All they do is automate copying and pasting in shit from StackOverflow.
We were closer to everyone being able to learn how to program computers in the mid-80s when everyone had one and they started up with a BASIC prompt.
Literally everyone had a ZX Spectrum, or Commodore 64, or a BBC Micro if their parents were rich and thought that having the same as they had at school was a good idea.
For CRUD apps, the API spec and UI mockups -- or even a photo of how it looks on the already coded platform -- would go a long way. That's exactly the kind of well defined task work LLMs do well with. It should be possible to automate a lot of the equivalence testing too.
Is there still an excuse for "maybe we'll add Android someday" or "not enough Mac/Linux users"? And is there still a justification for not building those less-used flows like password reset into the iOS app instead of throwing up random WebViews?
For those apps that do have non-trivial logic on device, LLMs have shown a lot of promise at rewriting to cross-compiling-is-easy languages like Go or Rust.
My original spicy take is: why learn SwiftUI at all at this point? It's a skill that, for most tasks, falls into the same kind of bucket as "learning Microsoft Word really, really well". I appreciate people who take the time to do that, but the outcomes are within millimeters of each other whether or not we do that.
I don't think that's true of programming generally. But I think there are languages now where the rationale in specializing in them has gotten, hrm, more complicated.
Over the years I've replaced 90% of the plugins I used when I started. Plus I get a nice outlet from any pesky NIH symptoms.
In all honesty, when you start up emacs for the first time with a blank config, it looks terrible. But then you start building it up with plugins and adding code to support your own quirky workflows and slowly it becomes too powerful in your life to ignore. I have not been able to drop it for 13 straight years. With AI taking over the development experience, emacs and neovim have only become even better, because now you can get AI to bake your custom workflows into the config for you.
Emacs/neovim should be the gold standard for all workflow tools.
I make small config changes every day and its super fun to use my computer this way. I wish everything was configurable like Emacs.
edit: typo
It is? Why? I read monospaced text all day long. I don't find it fatiguing in the least. In fact, I think I might prefer it to non-monospaced text.
When my Emacs opens a markdown file it immediately converts it into OrgMode format. I find that more readable, more navigable and more editable.
Now I'll have to go and meditate about Emacsification.
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.
It's not "about" Emacs, it's more about the vibe of personalized software in 2026 to someone who does a lot of Emacs stuff.
Another thing is configuration (which also ties to the previous statement). You have to be able to split the idea of the program (what it aims to do) and your personal preferences. Emacs make that easy by having a framework for user preferences. That makes for an extendable program.
The closest, but not as user friendly is unix and suckless philosophy combined. Small programs, easy to understand, configure, and extend.
Besides being an everything app for you, Emacs is an (unconventional) operating system with weak boundaries between user apps. It makes it easy to modify anything, write new things, or combine two existing ones with very little code, something that e.g. Microsoft could have only dreamed of in Office with its awkward embedding that barely worked. Emacs is one the few survivors of the idea that users should program what they need, which was popular during the personal computing revolution in the 80's. Two others are spreadsheets and BASIC.
Programming turned out to be too complex for the untrained users to handle, but AI makes the idea of custom one-off apps or weird hybrids pretty damn close, that is true in practice. I see a lot of people that vibe code their own little things to get things done. That's precisely what BASIC (often shipped in the stock ROM!) was supposed to be used for.
I think that "the number of programs" you're suggesting is arbitrary. It's kind of like calling an operating system one thing, when it's a lot of things. You can "count" the things different ways.
The bigger takeaway is "making your own programming things."
Most other "knowledge" professions -- by which I mean teaching, programming, some engineering, and the arts -- are even further along into obsolescence. That said, you can still use the knowledge gained in a knowledge profession to convert into a more hands-on profession. We might have a bit longer before humanoid robots destroy all hands-on job opportunities as well. Once that happens, every person will be equally poor and destitute.
I'm using Emacs since last century and I've got 3 000+ lines of custom Elisp code I wrote (with maybe only a few hundred lines copy/pasta'ed from other configs).
I'm always using a recent Emacs compiled from source and now with LSP, org-mode, Magit, tree-sitter, ivy/avy/counsel/swiper with ripgrep (thanks burntsushi) integration etc.
I had zero frigging idea what gfm and gfm-view for Emacs were.
But I'll look into it now!
Software production is so easy now that everything is a .emacs file: meaning, each individual has their own entirely personal, endlessly customizable software cocoon. As the article says, it's "easier to build your own solution than to install an existing one" - or to learn an existing one.
A similar analogy, not by concidence, is Lisp in general. The classic knock against it—one I never agreed with but used to hear all the time—is that Lisp with its macros is so malleable that every programmer ends up turning it into their own private language which no one else can read.
Tangential to that was Mark Tarver's 2007 piece "The Bipolar Lisp Programmer" which had much discussion over the years (https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%2...). He wrote about the "brilliant bipolar mind" (BBM) - I won't get into how he introduces that or whether it's fair or not, but it's interesting how mental illness comes up, given how "AI psychosis", in both ironic and unironic variants, is so frequently referred to these days.
From Tarver's article (https://www.marktarver.com/bipolar.html):
The phrase 'throw-away design' is absolutely made for the BBM and it comes from the Lisp community. Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp [...] No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine. This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something.
Sounds pretty 2026, no? He goes on:
The C/C++ approach is quite different. It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere. And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one).
The flip side of all this is that when production is so easy, the bottleneck becomes consumption, and sharing turns into an unsolved problem. This is why the Emacs analogy is so good. A .emacs file is as personal as a fingerprint. You might copy snippets into yours, but why would you ever use another person's? (other than as a way to get started as a noob). You just make your own.
The more customized these cocoons get, the harder they are for anybody else to understand—or to want to. This distinction is important. It isn't just that somebody else's cocoon has too high a cognitive cost to bother learning, when you can just generate you own. It's also uncomfortable, like wearing someone else's clothes. It's as if the sense of smell gets involved.
Rather than ai psychosis, we could call this ai solipsism.
In software it's fascinating how configuration management (that boringest of all phrases) is becoming the hard part. How do you share and version the source? What even is the source? Is it the prompts? That's where the OP heads at the end: "share it somewhere — or, better yet, just a screenshot and the prompts you used to make it." But when I floated a couple trial balloons about whether we might use this for Show HN—i.e., don't just share the code you generated, because that's not the source anymore; instead, share the prompts—we got a lot of pushback from knowledgeable people (summarized here: https://news.ycombinator.com/item?id=47213630).
These dynamics must be what's behind the pipe-bursting pressure that Github has been under. What a Github successor might look like is far from clear, but as a clever friend of mine points out, it's likely that there will have to be one. Projects and startups along these lines are appearing now, but we seem to be in the horseless carriage phase still.
Even more importantly, what happens to teamwork? To put it in Tarver's terms, if we are all a BBM now—or rather, we all have armies of cheap BBMs, permanently locked in the manic phase, waiting at all hours to generate things for us-and-only-us—how do we work together? How do cocoons communicate, interoperate? How does a team of ai solipsists function? It sounds oxymoronic.
My sense is that a lot of software teams, startups and so on, who have been on the cutting edge of AI-driven / agentic development, are currently grappling with this, not (only) philosophically but in very practical ways. e.g. how does my generated code compose with your generated code. With these issues, we end up giving back some of the productivity gains of generated code in the first place, and it makes sense that these effects show up over time, as the systems being built this way grow in complexity and the maintenance/development tradeoff becomes a thing.
No one seems to talk about it publicly. It makes sense that no one wants to be the first to stop clapping and sit back down during the endless standing ovation, but it's too bad that we can't (yet) talk seriously about the downside that accompanies this upside, as it does any upside. (I mean on real software teams building real systems, not AI/society thought pieces.)
[editing - bear with me...]
The "0% product hunt, 100% show and tell" bit is one of the benefits of an ecosystem with painfully high upfront entry costs.
Does anyone know of an active forum of any kind (discord, reddit, phpbb, mailing list, whatever) for people who are building personal applications like this for love of the game, which takes hardline stances about desirable vs undesirable motives and behaviors, and enforces high entry/participation costs in exchange for unusually low quantities of transient grifters and self-interested status seeking by day-old accounts?
The reason people who like emacs write their one-off program in emacs is that it is an extraordinarily introspectable and debuggable programming environment. There is no "code, compile, run" loop - you just write code against the live running environment. Devoid of that fast feedback loop, writing code just isn't as much fun.
> monospaced and thus fatiguing to read.
Monospaced text is fine. I don't see how people who read code (and code comments) all day care that strongly about this. Plaintext is king
But the beauty of this moment is that if you want a really good SwiftUI monospaced Markdown reader, you can have it before dinner. This is exactly what I'm talking about. You have an idiosyncratic personal preference, and it's now reasonable to expect software to shrink-wrap around that preference.
Also, are browser text area inputs monospaced by default for everyone? Or did I configure that for myself long ago and forget? If it's not just me, maybe the "reasons" you're alluding to are not so obvious. Anyway, I have no trouble at all reading the long comments I type into text areas.
And more power to people for embracing agency :)
Legacy decisions as a remnant from a time when taking more space on paper cost pages and therefore resources, remaining as a default from centuries of inertia in how text is printed?
But seriously: you do you. There are people who code in proportional typefaces and they're as baffling to me as you are right now. Let a thousand Markdown viewers bloom.
The legacy is proportional, at least in Latin script and its ancestors. Handwriting was proportional, of course, and so was Gutenberg's printing press. Books and newspapers have virtually always been printed in proportional type.
In Chinese and Japanese, monospace is legacy in both handwriting and print... and also still universally used today. All Chinese and Japanese text is monospaced by default. Billions of people are getting by just fine reading monospaced prose.
I don't really know where this conception that monospaced is somehow objectively harder to read is coming from. Actually, this is the first I've ever heard of the complaint. I can't help but wonder if you've been subjected to some very bad monospaced fonts in prose or something.
https://dl.acm.org/doi/epdf/10.1145/2897736
And why did you author them in LaTeX if you think reading in monospace plaintext is fine for everyone?
https://monaspace.githubnext.com/
The whole entire point of computers in their best light is changeable software, the whole point should be "let people read how they want to."
Specifically the idea that people generally just ignore existing versions of packages and make their own has never been the case, especially compared to other editors (even VSCode).
> There are popular elisp packages lots of people use. But except for Magit, nerds are alarmingly apt to replace them with their own shinier versions (and then to show them off, transitioning to the spore-forming phase of the elisp lifecycle). Everything in Emacs is malleable.
> Until now, the Achilles heel of Emacs culture has been that, except for Magit, its packages tend to be wretched user experiences. Ugly, slow, and discoverable only after inflicting years of elisp cortical injuries on yourself.
But...I like MDV.
"Content creation for an audience of one" is really the revolutionary change that is happening right now because of AI. Disposable apps, disposable books, disposable movies, disposable music. Things that are made for a single person, used once or a handful of times and then thrown away. The entire economic model of content creation and distribution is going to explode in the next 3 or 4 years, and very few people are prepared for it.
> The entire economic model of content creation and distribution is going to explode in the next 3 or 4 years
I think this is also inherently self-contradictory. What's the point of distributing content made for one? This gets into the same fallacy that people engage in w.r.t. "applications for one" displacing software developers. Yes, LLMs can pump out buggy software that suits one person's needs, and it doesn't need to be reliable enough to deploy at scale. It serves real utility here, because there was a gap between "the value of such software" and "what software developers are willing to work for", which meant that this software wasn't being created because there wasn't economic value in it. But then, how does one suppose software that has no economic value is going to replace all the professional software developers who were being paid to produce software that has economic value? LLMs filled a gap software developers weren't being paid to do, but given that they were not paid to do it, their jobs are not contingent on the existence of this niche. It simply doesn't follow that being able to produce content with zero economic value, whether that's applications or content for one, will cause an 'explosion' in the existing economic models.
If this is the starting thought, I don't know how you wrap back around to publishing and advertising the generated code.
Either you create the best possible mac markdown viewer and should share it as that, orthogonal to any statement of AI use. Or you're just adding to the noise of tools available online. Where other people should ignore your work, and go slopcode their own markdown viewer.