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.
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.
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.
"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.
> We're not there yet but with LLMs we're getting closer.
I feel I'm there. Whenever I have a problem I definitely ask "should I vibe code an app for that?"
My current Swift app has 15K LoC (5K in tests, 10K implementation) and it is finished. Like, there are minor improvements now, but it does what it needs to do. It took me 20 hours. I think the actual thing would personally take me 500 hours as I haven't programmed in Swift.
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.
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?
> 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.
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.
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.
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.
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.
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. oh well, shame is good for writing. envy too!)
Software production is now so easy that everything is a .emacs file (pronounced "dot emacs" btw): meaning, each individual has their own entirely personal, endlessly customizable software cocoon. As tptacek says in the OP, it's "easier to build your own solution than to install an existing one" - or to learn an existing one.
Another good analogy, not by concidence, is to 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 fairly or not, but it's interesting given how "AI psychosis", in both ironic and unironic variants, is frequently mentioned 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).
---
When production is so easy, consumption becomes the bottleneck [1], and suddenly sharing is a 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 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. It isn't just that another'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. The sense of smell somehow gets involved.
I would call this, maybe not AI psychosis, but 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 scre...
Maybe it’s just another cocoon but I’ve been working on a framework for modular CLIs which allow different humans or agents to spin different features simultaneously but with some enforcement of shared dictionary, aliases, help, logging, formatting, semantic parsing, a few other things.
It works, it’s powerful, and certainly one way to answer the question you pose. I would argue it’s the optimal answer, it’s an answer to RPC, REST, and MCP at the same time, but it’s definitely an example of an answer and approach. In any case it is a good question and something I’ve given a lot of thought to.
Unfortunately in the age we’re in now there’s something lackluster in sharing any solution or design you have. Though the architecture and design of what I’m describing came 0% from AI everything is assumed to be and therefore unimportant? But it is the direct answer to your question so if anyone’s curious lmk.
I highly agree with the pro-Lisp sentiment. The main article that comes to mind while reading this was also posted a little while back on this forum: https://isene.org/2026/05/Audience-of-One.html
I would add to that a few more open questions that I haven't seen addressed:
- As more engineers (and non-engineers) pick up coding agents, everyone is authenticating multiple MCPs, creating an n * n explosion of complexity that is impossible to centralise. Multiply this by the number of distinct coding agents for every platform and visibility is very tough. A lot of platforms also don't support scopes so you can't enforce safety short of a network proxy I suppose
- For non-developers mainly, lacking mental models such as <agent> for Y desktop app does not imply that there is a local LLM running on your machine. I suppose it's a question of trust and education versus starting conservative and progressively onboarding where we're more of the former.
- We talk a bit about the idea of sharing prompts but that fundamentally a prompt does not in itself contain quality. I've had internal tools I've made where it's mentioned that Claude made it when I mean, yes to a degree but I did many iterations using my own taste to refine things and held opinions about how things should operate. Giving someone a prompt won't inherently guarantee anything of quality. I often think about the idea of ie; give a screenshot of Github to an LLM but in a way, you're saying to create a clone, not of what exists today but is a dead echo of the design taste and choices made years ago that persist today. You can create things cheaply but without taste and good judgment, how can you continue to evolve it in a way that isn't like that draw the rest of the horse meme.
- I personally wonder about tokenmaxxing stories you hear about from other companies and like, logically what happens to glue roles? Does someone like a Microsoft just stack rank on token count and fire those who actually get work done? I suppose they already hollow out knowledge anyway so maybe it's nothing new.
- Definitely the thing with internal tooling where eventually you generate so much that you fundamentally have no mental model. It's fine for non-critical stuff and I'm kind of coming around to the idea that it's actually a better position to have no idea of the code and a strong "theory" of how a thing should work than it is to fully understand the code and have zero "theory". Ideally both of course.
Anyway, this isn't a comprehensive ramble but I've also been a bit disappointed that there hasn't been more talk about the second order effects. Many things can be true at once where you can see value in LLMs while still being critical of them and the whole DC situation ie; Colossus 1 etc.
> As tptacek says in the OP, it's "easier to build your own solution than to install an existing one" - or to learn an existing one.
I can install WhatsApp in a few tens of seconds. You most definitely spent more time than that writing this comment.
Would you mind sharing a video of you building a custom WhatsApp in less time? Not even starting to think about getting other people to talk to you on your instantly-built messaging solution...
Don't often see the great Dang commenting in a non-moderation capacity, and that's really a shame, because this is one of the most interesting, well-formulated comments I've seen on here for a while. I fully agree with your frustration with the AI zeitgeist, but I won't pretend to have any input to alleviate that frustration. I would love to much less eloquently rant about lisp(and emacs) and other vaguely related things for a bit though, so here goes.
The tendency for the Lisp community to self-segregate into these bubbles is something that's perplexed me for years. You noted that you don't agree with it; I'd in be interested in why. I do agree with it, in the sense that this phenomenon does occur to an extent, and certainly to a larger extent in Lisp compared to other languages. The part I don't agree with is that this is a universal deal-breaker for Lisp. And there's still plenty of cooperation and sharing in the Lisp community. Emacs once again is the prime example. Yes, every .emacs is as unique as a fingerprint. But the reason GNU Emacs refuses to die is precisely its wonderful ecosystem of extensions that have in fact been shared and maintained by a wider community. And this ecosystem is in part possible because GNU Emacs is devoid of any sort of boundary between application code and extension code, which is a philosophy that can be traced back to the LISP machine era.
It's also interesting to tie this in with RMS(the author of GNU emacs, what a coincidence!) and his stance on Free Software really being about every individual user being free to modify the software they run. Of course, the deep implications of this philosophy, and its implementation in Emacs and other Lisp software, are clear to me, because I'm a Lisp programmer, just like RMS. And the Free Software movement originated in a time when most people with access to a computer had at least some amount of familiarity with programming. But as computing has become mainstream, RMS' original vision has morphed, and the focus has been on the importance of the wider community being able to modify software. And that's certainly important. But it's not really free software in the original sense unless you happen to be a programmer. Most software users today are not programmers and likely never will be, so regardless of how the software they're using is licenced, they're not really free in that original sense, are they?
Then LLMs showed up. And suddenly, I can see on the horizon a revival of free software in the original sense. And yet it feels quite far away. For this to become reality, we need a lot more than what we have currently, which is a pretty damn good search engine/meme generator for the "normies", and a pretty damn good boilerplate generator for the coders. I think we probably need an entirely new concept of what software even is. I think we probably need new foundational research. I don't necessarily see a role for current LLM architectures in this. I feel more like current SOTA is scratching at the surface of the real deal, and it may take a few years to understand how to make foundational progress. Maybe we even need another AI winter to force the capital expenditure into other avenues. Certainly we need foundation models that are open in all possible senses of the word. Being tied to proprietary, heavily censored blob running in a giant datacenter is a non-starter.
It seems like the majority of people in the field have some intense tunnel vision about LLMs and transformer architectures. I'd love to see more variation there. I know Lecunn is doing some unique stuff. I can't pretend to understand whether it has legs, but I applaud the effort. Certainly we need to address the issue of energy expenditure, the absurd amount of data and training iterations required, and the lack of online learning. Human brains are vastly superior at all 3 of those metrics. So like, how about addressing that instead of just build...
I have vibe coded 3 applications I never had time to code but always wanted.
Now it is different in a way where now I don’t have time to use those apps.
That’s a joke. But it tells something about consumption problem.
Other thing is that a lot of software is useful only if lots of people use it over long periods of time. If every corporate employee vibe codes his thing then maybe it is better if they stick with Excel.
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.
Edit: Sure there is some small overlap here, but it's really not comparable and definitely not like the way the author describes things. User personalization in Emacs has normally been on a much smaller scale than rewriting entire packages. Configuration is generally smaller tweaks or things on top of existing packages because Emacs provides cohesive extensibility to the point that it often doesn't require "rolling your own." Most packages are already extremely configurable and tailorable. You don't magically get that sort of environment with LLMs. Emacs is much more cooperative/generalized.
The scale and type of custom/personalized software we're seeing now with AI is completely different from how things have been in Emacs. I'm not saying that's a good or bad thing (I think it's both), but it's very different from Emacs and definitely more comparable to something like vim/neovim where (in part just because of the sheer popularity) you constantly have people "rolling their own" packages and a billion versions of everything. Even that is not a great analogy. This is something completely new.
I have never heard of such an editor, and the name is exquisitely unsearchable. Even if I explicitly try to tell the search engine that I'm looking for a text editor that's a variant of vim, I just get results about using vim on a Raspberry Pi.
> When my Emacs opens a markdown file it immediately converts it into OrgMode format.
I want that. Can you give some details?
A search finds modeverv/markdown-to-org which looks 80% there but activates based on a yank or converting an already loaded markdown buffer. Perhaps it can be made to apply on opening a .md file.
Lots of interesting takes that I think I disagree with here, although I mostly write Markdown rather than read it:
> 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.
88 comments
[ 4.4 ms ] story [ 92.8 ms ] threadOver 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.
"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.
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
I feel I'm there. Whenever I have a problem I definitely ask "should I vibe code an app for that?"
My current Swift app has 15K LoC (5K in tests, 10K implementation) and it is finished. Like, there are minor improvements now, but it does what it needs to do. It took me 20 hours. I think the actual thing would personally take me 500 hours as I haven't programmed in Swift.
> 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
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?
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.
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.
edit: typo
Software production is now so easy that everything is a .emacs file (pronounced "dot emacs" btw): meaning, each individual has their own entirely personal, endlessly customizable software cocoon. As tptacek says in the OP, it's "easier to build your own solution than to install an existing one" - or to learn an existing one.
Another good analogy, not by concidence, is to 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 fairly or not, but it's interesting given how "AI psychosis", in both ironic and unironic variants, is frequently mentioned 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).
---
When production is so easy, consumption becomes the bottleneck [1], and suddenly sharing is a 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 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. It isn't just that another'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. The sense of smell somehow gets involved.
I would call this, maybe not AI psychosis, but 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 scre...
It works, it’s powerful, and certainly one way to answer the question you pose. I would argue it’s the optimal answer, it’s an answer to RPC, REST, and MCP at the same time, but it’s definitely an example of an answer and approach. In any case it is a good question and something I’ve given a lot of thought to.
Unfortunately in the age we’re in now there’s something lackluster in sharing any solution or design you have. Though the architecture and design of what I’m describing came 0% from AI everything is assumed to be and therefore unimportant? But it is the direct answer to your question so if anyone’s curious lmk.
seriously?
https://news.ycombinator.com/item?id=47393437
I would add to that a few more open questions that I haven't seen addressed:
- As more engineers (and non-engineers) pick up coding agents, everyone is authenticating multiple MCPs, creating an n * n explosion of complexity that is impossible to centralise. Multiply this by the number of distinct coding agents for every platform and visibility is very tough. A lot of platforms also don't support scopes so you can't enforce safety short of a network proxy I suppose
- For non-developers mainly, lacking mental models such as <agent> for Y desktop app does not imply that there is a local LLM running on your machine. I suppose it's a question of trust and education versus starting conservative and progressively onboarding where we're more of the former.
- We talk a bit about the idea of sharing prompts but that fundamentally a prompt does not in itself contain quality. I've had internal tools I've made where it's mentioned that Claude made it when I mean, yes to a degree but I did many iterations using my own taste to refine things and held opinions about how things should operate. Giving someone a prompt won't inherently guarantee anything of quality. I often think about the idea of ie; give a screenshot of Github to an LLM but in a way, you're saying to create a clone, not of what exists today but is a dead echo of the design taste and choices made years ago that persist today. You can create things cheaply but without taste and good judgment, how can you continue to evolve it in a way that isn't like that draw the rest of the horse meme.
- I personally wonder about tokenmaxxing stories you hear about from other companies and like, logically what happens to glue roles? Does someone like a Microsoft just stack rank on token count and fire those who actually get work done? I suppose they already hollow out knowledge anyway so maybe it's nothing new.
- Definitely the thing with internal tooling where eventually you generate so much that you fundamentally have no mental model. It's fine for non-critical stuff and I'm kind of coming around to the idea that it's actually a better position to have no idea of the code and a strong "theory" of how a thing should work than it is to fully understand the code and have zero "theory". Ideally both of course.
Anyway, this isn't a comprehensive ramble but I've also been a bit disappointed that there hasn't been more talk about the second order effects. Many things can be true at once where you can see value in LLMs while still being critical of them and the whole DC situation ie; Colossus 1 etc.
I can install WhatsApp in a few tens of seconds. You most definitely spent more time than that writing this comment.
Would you mind sharing a video of you building a custom WhatsApp in less time? Not even starting to think about getting other people to talk to you on your instantly-built messaging solution...
The tendency for the Lisp community to self-segregate into these bubbles is something that's perplexed me for years. You noted that you don't agree with it; I'd in be interested in why. I do agree with it, in the sense that this phenomenon does occur to an extent, and certainly to a larger extent in Lisp compared to other languages. The part I don't agree with is that this is a universal deal-breaker for Lisp. And there's still plenty of cooperation and sharing in the Lisp community. Emacs once again is the prime example. Yes, every .emacs is as unique as a fingerprint. But the reason GNU Emacs refuses to die is precisely its wonderful ecosystem of extensions that have in fact been shared and maintained by a wider community. And this ecosystem is in part possible because GNU Emacs is devoid of any sort of boundary between application code and extension code, which is a philosophy that can be traced back to the LISP machine era.
It's also interesting to tie this in with RMS(the author of GNU emacs, what a coincidence!) and his stance on Free Software really being about every individual user being free to modify the software they run. Of course, the deep implications of this philosophy, and its implementation in Emacs and other Lisp software, are clear to me, because I'm a Lisp programmer, just like RMS. And the Free Software movement originated in a time when most people with access to a computer had at least some amount of familiarity with programming. But as computing has become mainstream, RMS' original vision has morphed, and the focus has been on the importance of the wider community being able to modify software. And that's certainly important. But it's not really free software in the original sense unless you happen to be a programmer. Most software users today are not programmers and likely never will be, so regardless of how the software they're using is licenced, they're not really free in that original sense, are they?
Then LLMs showed up. And suddenly, I can see on the horizon a revival of free software in the original sense. And yet it feels quite far away. For this to become reality, we need a lot more than what we have currently, which is a pretty damn good search engine/meme generator for the "normies", and a pretty damn good boilerplate generator for the coders. I think we probably need an entirely new concept of what software even is. I think we probably need new foundational research. I don't necessarily see a role for current LLM architectures in this. I feel more like current SOTA is scratching at the surface of the real deal, and it may take a few years to understand how to make foundational progress. Maybe we even need another AI winter to force the capital expenditure into other avenues. Certainly we need foundation models that are open in all possible senses of the word. Being tied to proprietary, heavily censored blob running in a giant datacenter is a non-starter.
It seems like the majority of people in the field have some intense tunnel vision about LLMs and transformer architectures. I'd love to see more variation there. I know Lecunn is doing some unique stuff. I can't pretend to understand whether it has legs, but I applaud the effort. Certainly we need to address the issue of energy expenditure, the absurd amount of data and training iterations required, and the lack of online learning. Human brains are vastly superior at all 3 of those metrics. So like, how about addressing that instead of just build...
That’s a joke. But it tells something about consumption problem.
Other thing is that a lot of software is useful only if lots of people use it over long periods of time. If every corporate employee vibe codes his thing then maybe it is better if they stick with Excel.
But...I like MDV.
Edit: Sure there is some small overlap here, but it's really not comparable and definitely not like the way the author describes things. User personalization in Emacs has normally been on a much smaller scale than rewriting entire packages. Configuration is generally smaller tweaks or things on top of existing packages because Emacs provides cohesive extensibility to the point that it often doesn't require "rolling your own." Most packages are already extremely configurable and tailorable. You don't magically get that sort of environment with LLMs. Emacs is much more cooperative/generalized.
The scale and type of custom/personalized software we're seeing now with AI is completely different from how things have been in Emacs. I'm not saying that's a good or bad thing (I think it's both), but it's very different from Emacs and definitely more comparable to something like vim/neovim where (in part just because of the sheer popularity) you constantly have people "rolling their own" packages and a billion versions of everything. Even that is not a great analogy. This is something completely new.
I have never heard of such an editor, and the name is exquisitely unsearchable. Even if I explicitly try to tell the search engine that I'm looking for a text editor that's a variant of vim, I just get results about using vim on a Raspberry Pi.
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.
I want that. Can you give some details?
A search finds modeverv/markdown-to-org which looks 80% there but activates based on a yank or converting an already loaded markdown buffer. Perhaps it can be made to apply on opening a .md file.
> 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