I don't see change being as rampant as all that. You hear about the change on places like HN, and people talk about it, and startups try many new things. But the bulk of coding is quietly being done on corporate systems that are slow-moving and relatively stable, often on legacy systems. There just isn't much to say about that work, so we don't talk much about it.
I've been in the Apple world for the last decade or so, but everything I've seen with SwiftUI feels like it's only been done to attract web developers who are used to React; the "magic" observables etc. seem to be just a bit unstable and a pain to debug when they do go wrong, but even when they're working as intended they still make it harder to work with than the old UIKit way of doing things, where manually observing changes to state could be as simple as a `didSet {}` block, or using NotificationCenter.
All that stuff about how SwiftUI is supposed to make it "simple" or "easy" to make a UI is nonsense: we had "simple" with Interface Builder. And with VisualBasic's cross-platform cousin, Xojo.
I’m mostly web/backend so not deep in iOS, but SwiftUI does look like yet another case of abstracting away control in the name of “ease.” Same pattern with React: move logic to declarative bindings, then spend hours debugging state sync and lifecycle quirks.
UIKit with didSet {} or NotificationCenter might be verbose, but at least you can see what’s going on. SwiftUI’s “magic” feels like trading simplicity for opacity.
And yeah, Interface Builder, VB, even Delphi gave visual control without hiding everything. Declarative UIs sound elegant until you need to trace why a view is re-rendering 7 times in a scroll.
Brutal truth: most software engineers engineer for the sake of it. Experienced and not.
For the art (more complex system you create - more fun and challenges you will get) and for the money (more complex system you create - more work you create for yourself and colleagues, job security).
Playing with new shiny toys fulfills both desires.
That doesn't mean toys are not getting better. They do. Slowly. Because business keeps the pressure on shipping the results, not spending time fighting another js bundler configuration hell or SuperFancyNewAbstractFactoryBuilderSpringKillerWebFramework.
We don't think about business and don't like to think about it. We want to feel very important, we hate to realize that most of the time we are just tools to reach business goals.
Modern programming is a scam like most other bureaucratic work, so yes, definitely it's more about staying busy with convoluted work rather than delivering real solutions to real problems. You're not going to get people to admit it though, since their paycheck depends on it.
I don't see change being as rampant as all that. You hear about the change on places like HN, and people talk about it, and startups try many new things. But the bulk of coding is quietly being done on corporate systems that are slow-moving and relatively stable, often on legacy systems. There just isn't much to say about that work, so we don't talk much about it.
That's very true. Lots of Java, C++ in big companies / enterprise systems that "just work" for a long time
I agree with your sentiments: https://benwheatley.github.io/blog/2025/02/26-14.04.07.html
I've been in the Apple world for the last decade or so, but everything I've seen with SwiftUI feels like it's only been done to attract web developers who are used to React; the "magic" observables etc. seem to be just a bit unstable and a pain to debug when they do go wrong, but even when they're working as intended they still make it harder to work with than the old UIKit way of doing things, where manually observing changes to state could be as simple as a `didSet {}` block, or using NotificationCenter.
All that stuff about how SwiftUI is supposed to make it "simple" or "easy" to make a UI is nonsense: we had "simple" with Interface Builder. And with VisualBasic's cross-platform cousin, Xojo.
I’m mostly web/backend so not deep in iOS, but SwiftUI does look like yet another case of abstracting away control in the name of “ease.” Same pattern with React: move logic to declarative bindings, then spend hours debugging state sync and lifecycle quirks.
UIKit with didSet {} or NotificationCenter might be verbose, but at least you can see what’s going on. SwiftUI’s “magic” feels like trading simplicity for opacity.
And yeah, Interface Builder, VB, even Delphi gave visual control without hiding everything. Declarative UIs sound elegant until you need to trace why a view is re-rendering 7 times in a scroll.
Brutal truth: most software engineers engineer for the sake of it. Experienced and not.
For the art (more complex system you create - more fun and challenges you will get) and for the money (more complex system you create - more work you create for yourself and colleagues, job security).
Playing with new shiny toys fulfills both desires.
That doesn't mean toys are not getting better. They do. Slowly. Because business keeps the pressure on shipping the results, not spending time fighting another js bundler configuration hell or SuperFancyNewAbstractFactoryBuilderSpringKillerWebFramework.
We don't think about business and don't like to think about it. We want to feel very important, we hate to realize that most of the time we are just tools to reach business goals.
Modern programming is a scam like most other bureaucratic work, so yes, definitely it's more about staying busy with convoluted work rather than delivering real solutions to real problems. You're not going to get people to admit it though, since their paycheck depends on it.
That's a rather wide brush you're painting with there...
Job security