> it's worth changing the environment to simplify the problem instead of writing complex software!
No doubt there is a fair amount of architecture astronautics out there, but thinking you're going to turn complex problems into simple problems by "changing the environment" is most of the time extremely naive. You can push against reality all you want, but reality tends to push back.
"Reality is going to push back." It's a tradeoff, but experience has shown that fixing the problem without software will cause fewer headaches in the long run than fixing it with complex software.
More seriously, there are many classes of problems which range from extremely impractical to impossible to tackle without software. The question is also, who is getting the headaches? If you pile up enough man-hours on the most awful software, it will eventually work satisfactorily. Customers don't give a damn about the underlying code, nor they should, they want a product that works.
At the risk of belaboring the point from my other sub-thread...
Suppose you've developed an application that has a graphical user interface. For the sake of simplicity, you rejected all of the overly complex GUI toolkits out there and rolled your own, with the assumption that all of your users can see what you're drawing on the screen. So you didn't implement your host platform's accessibility API (assuming you're running on a host platform with an accessibility API.) Now, a blind person needs to use your software. How do you fix that problem without software?
Beyond that specific example, the point is that, as the GP said, trying to change the environment to eliminate inherent complexity is often not feasible.
But I did something different: rather than wrap high-level APIs in even more higher-level APIs, I instead focused on making it "simple to express the math." So for a table, you could use data binding to simply express some constraints on cell width, height, adjacency, and so on. So I never bother using what WPF calls a table (or list or whatever); I would just use canvas and organize the cells using a few lines of math. That is quite liberating!
It is not always the case that GUI toolkit goes in the direction of increasingly more abstraction.
Most of the complexity in these GUI toolkits is unrelated to accessibility or other "essential but non-obvious" features, so I don't think this is a good point.
Most attempts at radical change will fail, does that mean it's not worth trying? Sometimes it does work, and the world becomes much better as a result.
As usual, the big issue is "do you actually understand the problem you need to solve?". Many problems are complex, either per se or due to constraints outside of your control. Maybe you don't like to have to implement a lot of complex code to interact with a terribly programmed legacy app, but if your customer pays you to do that, that's the kind of constraint you cannot really do anything about. When you look at it closely, my feeling is that you'll find a lot of apparently-unnecessary complexity is there for a good reason, and it's our job to make this complexity manageable.
It doesn't mean you shouldn't challenge existing paradigms. Innovate! Blow our minds! But just make sure you understand the problem you're solving first :)
As a researcher, I have freedom to constantly reinvent things. Complexity melts away the better you understand your problem: ya, it was there, it was needed, but now I know more and I can get rid of this. People in production don't usually have these benefits.
I have only made this letter longer because I have not had the time to make it shorter. - Blaise Pascal.
I think that's often true for blue-sky projects. And I agree that a better understanding of the problem can lead to a reduction in complexity, but you cannot always afford it.
As long as we are talking about reinventing programming, I think we can afford it. The problem is that once you are in production, you have to ship...this is what I always got from RPG's "worse is better!"
Of course, it's a matter of tradeoffs. It's particularly interesting to observe how Rust is moving along: since I started watching it, it has undergone a huge quantity of non-trivial changes. Which would tend to show that "worse is better" doesn't work for programming languages. Indeed, languages which have grown organically, like PHP, are not well-regarded. Maybe it's a question of surface: the smaller unpolished surface you expose to the outside, the faster you can ship something which will not turn into PHP later. If your CLI is not well thought-out, it's not a big problem, but you won't be able to make drastic, incompatible changes in syntax and semantics for a programming language with millions of existing lines (ask the Python 3 people :) ).
No doubt there is a fair amount of architecture astronautics out there, but thinking you're going to turn complex problems into simple problems by "changing the environment" is most of the time extremely naive. You can push against reality all you want, but reality tends to push back.