1. <https://www.winestockwebdesign.com/Essays/Lisp_Curse.html#ma...>
* Podcast apps
* Music listening apps
* Feed readers
* Bluesky clients
* Note-taking apps
* Desktop bookmarking/read-later apps
* Chat and instant messaging
* Time trackers
* Recipe managers
These are all things that you can get better-than-replacement-grade results from Claude on --- not necessarily the best, not necessarily the most globally competitive, but certainly an application more closely tailored to exactly what you want it to do for your own idiosyncratic work style.
Music.app is a miserable experience, and I can just tell as I use it that it's miserable trying to serve me. But Apple long ago factored all the meaningful bits out of Music.app into MusicKit. Why am I still using Music.app? MusicKit is the real product now. This is new.
But now it occurs to me: I know precisely how I work, I know what patterns are valuable to me, I know when and how I need to remind myself of things. I don't know why I haven't already started building my Things.app replacement. But I'd guess I have it to a place where I'm happy by this time Saturday.
Honestly, it's harder for me to think of daily-driver apps where this wouldn't be the case. I guess vector graphics editing? I'm not going to vibe up a vector editor. But I'll bet all the money in my pocket that 5 years from now, the real value in vector graphics tools will be their API/SDK, not the packaged application experience.
For example, we can "reclaim" non-DRM ebook readers, audiobooks, and music players that play local files or use an open API. But a company-specific walled garden streaming DRM'd ecosystem will be almost impossible to build around.
I gotta be careful, I'm going to talk myself into staying up late tonight building that.
Ownership can have different forms. Slack.app that doesn't let me easily extract code snippets from a thread - owns me. Jira that forces me to use their imbecilic, quirky wysiwyg owns me. Note taking app that keeps the data in their db and not my files - ain't my friend. The friction is the ownership. When extraction requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay in Slack/Jira/Dropbox/Evernote/Notion/etc. longer, search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.
Plain text, local files, standard formats - they don't fight you on extraction because there's nothing to protect. That's why investing in FOSS tools is almost always paying for your own liberation rather than your own imprisonment. Even when there isn't feature parity, even when the FOSS tool doesn't have a "polished UI" and it's "maintained by a teenager in Nebraska" - still a better choice.
This is an experiment towards that:
https://github.com/dharmatech/9social
The first client is written for plan9. This keeps the design honest. (If it can run on plan9/rc/acme...)
Video demo:
The current implementation is less than 3000 lines of code.
And speaking of Emacs... 9social was heavily inspired by an Emacs project called Org Social:
I've been thinking of this as well:
Something like old school Facebook in UI, but functions more like MSN Messenger. You connect to your contacts via P2P, and download/upload updates to your social media network.
Yup, local-first is central to the design.
And, you only see who you explicitly follow.
I hope there's a sympy-thagoras out there.
( • ‿ • )
Their local-first approach inspired that aspect of the 9social design.
However, a big difference is that SSB is a sophisticated protocol.
With 9social, the heavy lifting is done by git and a set of conventions.
Thanks for checking it out!
"There's a filesystem for that."
¯ \ _ ( ツ ) _ / ¯
https://repo.autonoma.ca/repo/timeivy
An unfinished spreadsheet-based interface for entering time. Meant for consulting, but never got around to persisting the data. Mostly created it because I couldn't stand all the ways that time trackers force users to enter structured time when there's a cute algorithm to handle just about every way a human might naturally enter time.
https://stackoverflow.com/a/49185071/59087
* Recipe managers
https://repo.autonoma.ca/repo/recipe-fiddle
In the days of LLMs, it would be far easier to categorize ingredients and format them into TeX for publishing as a PDF file. The idea behind this project was to let people essentially copy/paste recipes off the web or scans of handwritten content and autoformat it.
Yep, I'm doing this all the time. I've been doing it for a year. The silliest on is an IG post previewer. My app is better suited to me than the preview function that Instagram provide itself.
Podcasts: audiobookshelf
Music: 500 different subsonic clients, many of which are good. Or some fun tuis
Feed readers: lol, more than there are grains of sand in Torvalds' flippers
Note taking: again innumerable, also, just use nvim or emacs of course
Chat: tons of very good self hosted options that can save orgs thousands a month.
Rather than build your own from scratch, rediscovering already solved issues, why not contribute to or fork a FOSS project? LLMs make it easy easier to get up to speed on large projects
The point of the post is the emacsification of the native macOS (and Windows, I assume) environment. Totally reasonable not to care that it's occurring, that's not really responsive to the post, is it?
Audiobookshelf has a native android app, not sure about desktop, I only use it on Android.
Anyone can build a TUI sure but why try to rebuild the whole mpd client/server stack that lets anyone on your network play music from the several TB collection of FLACs on your NAS? Same for subsonic, why reinvent the client server protocol there when it's already solved? And for subsonic clients, why reimplement streaming, offline downloads with de-duping, stream bitrate, album / artist handling... If there's something a subsonic client doesn't have that you want, fork it, point claude at it, done! That probably falls within the emacsification thing, right?
Email is right there waiting for disruption.
I'd say the thing with email that most improvements would need improved standards?
That said, as with the emacs user example, the ability to automatically process all your email in madly custom ways can now be opened to the masses.
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 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 can only be what's behind the pipe-bursting pressure that Github has been under. What a Github successor would look like is unclear, but as a clever friend points out, there will have to be one. Projects and startups along these lines are appearing, but we seem to be in the horseless carriage phase still.
Even more importantly, what happens to teamwork? If we are all a BBM now—or rather, if we all have personal armies of BBMs, locked in a manic state, primed at all hours to generate things for us-and-only-us—how do we work together? How do cocoons communicate, interoperate? What does a team of ai solipsists look like? It sounds oxymoronic.
My sense is that a lot of software teams, startups and so on, on the cutting edge of AI-driven / agentic development, are currently contending with this, not (only) philosophically but practically, e.g. how does my generated code compose with your generated code. With these frictions we presumably end up giving back some portion (how much? who can say?) of the productivity gains of generated code. One would expect such effects to show up over time, as the systems being built this way grow in complexity and maintenance/development tradeoffs become things.
I don't see many talking about it publicly yet though, which is a pity. No one wants to be the first to stop clapping and sit down during an obligatory standing ovation, but it's a bummer if you can't (yet) tell interesting stories about downsides and instead have to pretend that this is the first free lunch, the only downsideless upside that ever existed. It makes the discussion more boring and probably slows evolution since the experiments, ironically, are happening in silos.
These are the people doing the most serious and real and advanced work with the new tools (edit: I mean in the field of software dev), so it sucks if all talk of downsides is left to the cynical/curmudgeonly contingent, who for whatever good points they may, er, generate along the way, are obviously wrong about AI having no value for software dev. It's easier to talk about AI wiping out the human race than, say, bug counts going up or productivity levelling off after a while.
Mostly I just want to know what's really going on! and how people are dealing with it and how it is developing over time. Do I have to like go to meetups or something?
[1] That's why a recent paper used the title "Easier to Write, Harder to Read" - https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
Same deal with a lot of this software. I guess there's some "taste" to it, but mostly what you care about are the ideas and the "recipe".
Also, you should just do a monthly "Vibe HN" thread.
> you should just do a monthly "Vibe HN" thread
It wouldn't stop people from feeding them into the Show HN stream, which is the problem. If we had a good enough way to tell them apart, we could factor them into two streams, but we don't yet.
But it would allow for a culture to grow where the posters would self-contain their submissions into those threads.
1. erring on the side of sounding cooler
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...
I can concur with that thought direction. We used to pair and group-program on my team, we have a "Zoom office". Now it has become "let me take this ticket and feed it to Claude, you try the same thing with Copilot, and then we compare the results", or "I'd make a PR with my clunker, you use yours to review it". This shit honestly feels almost pointless. The pair-programming is absolutely dead. Who wants to watch me run several agents, trying to fix multiple things in different work-trees, while I'm juggling them around and fixing inconsistencies in my agents.md?
I've been pushing the idea of building a self-governing, fully autonomous cloud pipelines so we'd stop playing "stupid tokenomy" games, and it seems my management is just quietly trying to "keep it down", because I think there's a simple understanding - the moment that shit proves airworthy and actually can fly, a bunch of them are guaranteed to lose their cushy seats.
One example of teamwork is how the programmers and researchers worked together to build the UNIX SYSTEM (https://www.cs.dartmouth.edu/~doug/reader.pdf). It is not a product but an environment optimized for building tools and solving practical problems with tools written in C (while BBMs were busy with Lisp in Boston .;-)
C++ is a totally different story and you need an IDE for that.
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.
seriously?
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.
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 admit it's added up to more than zero though! Keeping (require 'cmake-mode) working reliably on Windows and macOS has proven a minor annoyance, and fonts seem to require a degree of system-specific attention.)
I honestly can't even relate to what that even means. I'm a programmer - my everyday job is all about changing the behavior of computer systems - local, remote, cloud, embedded, etc. Requirements change, scope fluctuates, problem space evolves - grows and shrinks, accretion is unavoidable. I need to routinely move between language stacks, different data types, formats, CLI and web tools, protocols, paradigms, OSS and proprietary apps.
That means I have to constantly adapt, my control plane has to keep up with the flux. Automation is key - you must develop a mentality for that - every little annoyance can be and shall be automated. That is an endless, non-stop transformation of my workflow - continuous maintenance of my tooling. But that is not some toilsome, reactive maintenance.
Thinking that you're a programmer that doesn't want to constantly build software for your own sake is a delusion - it's like a cook that hopes to turn on the stove only in the restaurant, but won't touch a knife at home.
Emacs is the cook's home kitchen. I'd say there are two kinds of maintenance: reactive (fixing breakage, keeping up with churn) versus generative (shaping tools to match your evolving understanding). Programmers instinctively dislike the first and should be drawn to the second. Emacs is almost uniquely suited to generative maintenance because the tool and the work share the same substrate.
I get your complaint about Emacs specifically, it's a common: "too much work to set up", which usually means: "I don't want to invest before I get value", which honestly is not wise, strategic thinking. Treating Emacs as the universal tool for minimizing total maintenance burden over a career, over a lifetime is.
Programming is also so much broader than something like cooking. It would be like saying that "you make your living manipulating matter, how could you not want to manipulate all that other matter?" to a chef. Their cooking doesn't necessarily make them want to mend clothes, remodel houses, devise new pharmaceuticals, etc.
I just disagree with why Emacs heavy users are often "blamed" to be obsessed with their tools "needlessly". What does it even mean to desire "as little maintenance as possible"? Okay, let's say I don't use Emacs (which is like I dunno over 90% of existing programmers in the world). What, I won't be writing bash scripts for my work? Okay, maybe I really hate Bash. Python then? Lua? Perl? What the hell are we even talking about? Of course, a programmer will do these things. Every programmer does. There's not a single case where a programmer doesn't tweak, re-tweak, personalize, improve, readjust their tooling, their scripts, browser extensions, the set of apps they use. Why is it Emacs and Vim considered a "perpetual maintenance", and I dunno, VSCode is "it just works™"? That's just not true. If I didn't use Emacs, I'd be inevitably re-inventing some workflow automation in some different way. Or what, bash-scripts ain't no software?
> Thinking that you're a programmer that doesn't want to constantly build software for your own sake is a delusion - it's like a cook that hopes to turn on the stove only in the restaurant, but won't touch a knife at home.
> Emacs is the cook's home kitchen.
The two sentences are adjacent. I read them as connected. If you meant them to be unrelated, I hope that this sheds light on our disagreement.
What I meant is that viewing Emacs merely as a means to achieve a singular goal and to extract specific value (e.g. "I've heard Magit is nice") is shortsighted - approaching it as a strategic, long-term investment yields far greater returns. I'm not preaching for absolutely every programmer to use it.
Come on, now tell me how I think of everyone who doesn't approve my web-browser tweaking habits as "catastrophic failures"...
Programmers write programs. That's the definition of the job. Any personal tweaks - scripts, snippets, extensions, packages, configs (for VSCode, IntelliJ, Vim and yes Emacs too) are also programs. Saying: "I don't want to maintain my programs" sounds to me like saying: "I don't want to be a programmer". It doesn't matter what I use - Emacs, Sublime or Macromedia Dreamweaver - configuring and maintaining it is not "kind of a job", "part of my job", or "someone else's job". That is my job as a programmer. Period. End of discussion.
Why the fuck you keep pouring your own made up shit from one pitcher into another, thinking it's about to turn into gold, is beyond me. And somehow I'm the dude that should "relax". Well, sure, let me then apologize for my inability to explain to you something that a six year old would get off the bat.
I don't owe you an explanation why I do it, why write anything at all. Why HN. I'll say it anyway. I do it because I still recognize people here. Living, dreaming, learning, fighting, hating, daring, loving people. I don't get paid for it, I don't seek recognition, I am not trying to build a name. I share my opinions because nothing is more important for our species than storytelling. And we need to share stories, listen to them, re-live them, learn from them. That's why many of us would go to watch Nolan's rendition of a 2700-year-old story. Even if we don't like the movie already.
And then someone like you comes, shits all over your charming writing, compelled to do it just because they see a word they don't like. Well, honestly, fuck you. Yeah, not nice, but I'd rather be kind and tell you the truth. You wouldn't be saying the shit you replied to me with to my face. Not because I have muscles, or am intimidating, or weak and miserable, no. But because you're definitely not a jerk, or an idiot. I wouldn't have to spend hours wasting on your ass for no good fucking reason. Seriously, I am a solo father with two kids, it's fucking 1:30AM and I'm having to deal with this shit, because writing for me is still fucking hard. English is beautiful, but hard. Come on, kid, think sometimes. For the sake of fellow humans.
So LLMs are good enough to make personal software, but not good enough to maintain them?
I don't want to spend time on dealing with change. Hence why I'd rather purchase tools, where I pay for the developer to a) prepare for any maintenance, and b) will perform the maintenance needed.
(Of course, the maintainability of software with current generation LLMs depends a lot on how well your architecture them. I've got pure vibe coded slop, that can be very difficult to wrangle.)
I mean... yes?
Maintaining software means looking at issues opened on github, keeping your own list of feature requests and bug fixes, deciding if and what to fix, deciding when to fix, and if you're lucky/cursed, reviewing PRs from randos. ANY of this means diverting attention from your day job/client work/kids/???.
Can some of this be theoretically automated by an LLM? Uh, maybe? But I'm not sure how much that would help.
There are no gatekeepers, no dependencies!
This, require you to have pay $20-$200 to a 3rd party corporation, or have a kind of beefy GPU (to run locally), run some instructions on text file, keep editing till it might does what you intend it to.
You are knowingly adding a dependency, which probably will become a hard dependency when everything goes jumbled up for human reviews, either on a beefy GPU or sending your data to a shareholder pleasing corporation.
Let's distinguish, how these are not the same, and the real price we pay
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.
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.
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!
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
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.
Google Search declined in quality when results started containing more noise (more ads, SEO spam) that required sifting through. Gemini isn't displaying all that garbage.. yet.
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.
They were cheap and ubiquitous, unless I suppose you were in one of "Iron Curtain" countries.
I suppose it's a bit like television, it would have been more popular where it was invented.
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.
It looks off and it’s suboptimal performance-wise. It was, I’d say, 80% of a proper SwiftUI app (which is really fantastic given it was basically a one-shot).
Actually knowing SwiftUI meant it was trivial for me to just close out that remaining 20% by hand and have an actually *nice* cross platform (iOS, iPadOS, macOS) app.
I’m sure I could have prompted it to get it done right but without proper knowledge on the subject I wouldnt even know what was wrong and Claude doesn’t do so hot with “that just feels wrong”. Beyond that it was quicker to do it myself, but maybe I just need to prompt better /:
If I'm shipping a product where each development/release cycle costs my team $5MM, I am absolutely going to spring for the professional SwiftUI developer.
But most things normal developers build in their spare time don't even cost $50 per cycle. Unless they're UI learning projects or projects by UI experts, there is no "budget" for UI. At best, for real labor-of-love projects, you get a TUI where the developer spends 5 hours of their life that they will never get back creating a 70%-functional terminal version of the affordances the native UI toolkit provides out of the box.
That's all over now. However competitive Claude-generated SwiftUI user interfaces are with expert SwiftUI projects, they roflstomp the UI options available to most developers. I can't say enough what a smoking gun the flickering Signal app is here!
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.