[IanSanders]

Is it time to redesign the entire technology stack?

Edit: Feels like half measures won't move us very far (and taking a step back and refactoring everything, taking into account lessons we learned, while awesome, would likely not be financially viable)

[KronisLV]

For better or worse, we'll eventually reach a stage a few centuries from now when the idea of rewriting all of the software that we're using won't be a matter of not having enough finances or manpower, but rather that the capacity of the human brain won't be able to deal with all of the layers upon layers of abstractions that will have accumulated.

Of course, perhaps it's therefore useful to improve the things that we can for now and push for more and more open software in all the levels of the stack, as opposed to introducing more and more abstractions and shiny new technologies before they're truly ready. Is Rust ready? I have no idea. Of course, people will always prefer having working software now rather than the ideal software for their grandchildren, as evidenced by the mentions of PL/I and the evolution of Linux.

[naasking]

I doubt that software will look anything remotely like what we have now, so I don't think I can agree about all of the layers of abstraction. If I were to hazard a guess, I'd say that software will be described by high-level specifications and compiled to running code subject to a separable executable specification (defining things like resource limits, allocation behaviours, latency requirements, etc).

Superoptimizers and machine learning will be used to ensure the final code conforms to all required specifications, so people generally won't be dealing with lots of abstraction layers in the way they do now.

[KronisLV]

> Superoptimizers and machine learning will be used to ensure the final code conforms to all required specifications, so people generally won't be dealing with lots of abstraction layers in the way they do now.

Have you seen the current state of model driven architecture and the state of trying to do metaprogramming of any sort?

The latter is very stack specific and is really hard to get right, whereas the former has never made its way out of academia. Admittedly, even the people who were forced to use something like the Eclipse Modeling Project ( http://www.eclipse.org/modeling/emf/ ) won't deny that there is definitely potential there, but to a large degree it has failed to materialize.

If there was as much hype around code generation as there was around the new releases of React, then maybe things would be different, but at large i personally doubt that the industry wants to take a step back and spend a decade on the building blocks, rather than getting things done in their day to day lives. Perhaps i'm really skeptical.

[naasking]

> Have you seen the current state of model driven architecture and the state of trying to do metaprogramming of any sort?

Sure, but you described circumstances "centuries from now". Your objection about not taking a step back for a decade or two due to immaturity evaporates on that timeline.

[IanSanders]

> capacity of the human brain won't be able to deal with all of the layers upon layers of abstractions that will have accumulated

That's already the case though.

Maybe we need to take a step back and design an elegantly simple, unambiguous, auditable/analyzable infrastructure, one that's more robust against becoming too complicated in the future. "Structural minimalism", to complement minimalism in user interfaces becoming more and more popular in the recent years.

[KronisLV]

> Maybe we need to take a step back and design an elegantly simple, unambiguous, auditable/analyzable infrastructure, one that's more robust against becoming too complicated in the future. "Structural minimalism", to complement minimalism in user interfaces becoming more and more popular in the recent years.

This sounds good, but in practice there are two types of complexity:

  - domain complexity, which pertains to the domain that we're working in and essentially is forced upon us by it
  - accidental complexity, which is created by all of the sub-optimal decisions and implementation details

You can and should minimize the latter, absolutely, but a lot of the former isn't viable - making systems simpler in some ways (memory allocation and access, for example) could make them perform noticeably worse. No one (amongst the end users) wants to have their hardware become slower, especially when Wirth's Law is still in full effect ( https://en.wikipedia.org/wiki/Wirth%27s_law ).

It would be nice if we could, but even booting operating systems nowadays gets more and more abstractions and complexities added, just look at what Microsoft are doing with Windows 11, essentially creating e-waste for controversial reasons. However, i think that people can at the very least still be competent within small subsets of the larger system, with clearly defined boundaries amongst them, as well as interfaces.

[kaba0]

There is no such thing. Useful computations are by necessity complex (in both a human-centric view, as well as from a computability view).

There are bad abstractions, of course. But this is just a hay dream that we can design a system that would be less complex than the essential complexity of the problem at hand - and dealing with all the hardware, networking, etc is just simply hard.

[worrycue]

> capacity of the human brain won't be able to deal with all of the layers upon layers of abstractions that will have accumulated

Isn't the point of abstraction so we don't have to deal with the complexity?

[mamcx]

Totally, and probably to be like the older but better stacks :)

ie: Amiga, BeOS, Plan9, HyperCard, FoxPro, ...

ie2: Is not as much a start from zero. Good ideas are not in short supply, is that the bad idea go a full speed and by pure mass it become bigger and bigger. Eventually, a clean start is 100% the cheaper option.

We are due that point!

Sadly, the BEST starting point for that was the introduction of the iPhone (to make stuff like this possible helps a ton to be along a game-change)