Live data from Hacker News

The Emacsification of Software

sockpuppet.org

91–100 of 304 posts

Re: The Emacsification of Software

#91
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.

https://github.com/codazoda/blue

Re: The Emacsification of Software

#93

Earlier quoted context omitted.

Ah yes, the 80s, when everyone had a computer.

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.

My house did not have a computer in it until 1992. I knew many people who did not have a computer in the house in the 1980s. Computers were expensive!

Re: The Emacsification of Software

#95
post #6

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…

> 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?

> So LLMs are good enough to make personal software, but not good enough to maintain them?

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.

Re: The Emacsification of Software

#96
post #42

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 exa…

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 programmi…

I’m a SwiftUI developer at $DAY_JOB so maybe biased but while Claude can make things that look right it’s still not exactly perfect. Especially from designs. I used Claude design to mockup a monitoring app for my talos cluster and Claude code totally freestyled it. What should have been as simple as `List { Section(“title”) { … } }` got morphed into whacky DIY `VStack {}.background(.gray)` nonsense.

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 /:

Re: The Emacsification of Software

#97
post #38
post #31

Earlier quoted context omitted.

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 e…

> 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 se…

> Oddly enough, Google’s LLM is the only one that has been answering my questions well on a research project these last weeks.

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.

Re: The Emacsification of Software

#99
post #42

Earlier quoted context omitted.

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 programmi…

I’m a SwiftUI developer at $DAY_JOB so maybe biased but while Claude can make things that look right it’s still not exactly perfect. Especially from designs. I used Claude design to mockup a monitoring app for my talos cluster and Claude code totally freestyled it. What should have been as simple as `List { Section(“title”) { … } }` got morphed into whacky DIY `VStack {}.background(.gray)` nonsense. It looks off and…

I have absolutely no doubt that an experienced SwiftUI macOS developer could easily produce better UI than Claude can today. The thing is, Claude produces better UI than a replacement-level macOS developer can, and, much more importantly --- this is really the core of my argument --- \infty better UI than a typical developer can produce, because most developers don't ever build native UI.

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!

Post reply on HN