"Simpler" from the user's perspective does require additional complexity under the hood.
It means that the "simpler" software has to be aware of all kinds of edge cases and solve them automagically, because the user expects a larger degree of automation. Software seems "simpler" to the user because it's working on a higher level of abstraction (and levels of abstraction tend to be "leaky") and by reducing the domain of details that the user needs to be aware of. In order to do that properly, the "simpler" software now needs code to take care of all those details as they are effectively removed from the user's awareness, while the earlier software could leave some of those edge cases up to the user.
> ""Simpler" from the user's perspective does require additional complexity under the hood."
No, it doesn't, or at least it doesn't if you write the application in a language that is expressive enough to cater for the edge cases without bloating the code base.
Consider a language like Red, which allows you to write GUI applications in a few lines of code. Must be a large runtime behind the scenes enabling this, right? It's clear that this is not the case as the runtime, compiler and libraries fit within 2MB. How is it possible for Red to achieve so much with so little? I'll leave that for you to discover for yourself.
The answer can't always be "a sufficiently-expressive language", same as the answer can't always be "a sufficiently-smart compiler". It looks like Red is a minimal programming language, with a purpose-built DSL ("dialect") for UI programming, which handles the "standardized" part. The final result of this line of thought would seem to be that everyone should use Lisp with layers of DSLs for whatever their target functionality is. Which works great, as long as those DSLs are complete, standardized, and mostly not leaky. In the spirit of your comment, I'll let you discover for yourself why that doesn't seem to happen.
EDIT: As an aside, the Java 1.1 JVM was only about 15MB.
> "Which works great, as long as those DSLs are complete, standardized, and mostly not leaky. In the spirit of your comment, I'll let you discover for yourself why that doesn't seem to happen."
Two reasons:
1. Computing is a relatively young field, and not all of the best practices have made it to the mainstream.
2. The quickest way to develop is to bolt additional code onto the side of a project rather than considering how the overall requirements for the software application may be better served by designing reusable helper functions and refactoring.
Also, I think you've dismissed Red a little too quickly. The GUI DSL is not the only factor that keeps the codebase compact. I'm using the word "compact" rather than "small" as I recognise that Red is still in its infancy, but with the word "compact" I'm trying to emphasise that Red does a lot with not a lot of code.
> "EDIT: As an aside, the Java 1.1 JVM was only about 15MB."
How big was the JCL (Java Class Library) at the same time? Also, 15MB for a VM on its own is not that impressive. Even Oracle have managed to make small (feature complete) VMs, for example:
"The resulting runtimes have peak performance competitive with the best hand-tuned language-specific compilers on the market. For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks."
"To give a feel for how easy it is to write these engines, TruffleJS is only about 80,000 lines of code compared to about 1.7 million for V8."
"The Substrate VM addresses those deficiencies by producing a static binary of a Truffle language runtime. It performs an extensive static analysis of the runtime, noting which classes and methods are used and stripping away the ones that are not. The AOT compiler then performs some up-front optimizations such as trivial method inlining and constructs the metadata necessary for Graal to perform its runtime optimizations. The final output is a version of the Truffle language interpreter fully compiled to native machine code; i.e., there is no Java bytecode anywhere. As an added benefit, the binary size is considerably smaller than the JVM’s because all the unused classes and methods are excluded."
It means that the "simpler" software has to be aware of all kinds of edge cases and solve them automagically, because the user expects a larger degree of automation. Software seems "simpler" to the user because it's working on a higher level of abstraction (and levels of abstraction tend to be "leaky") and by reducing the domain of details that the user needs to be aware of. In order to do that properly, the "simpler" software now needs code to take care of all those details as they are effectively removed from the user's awareness, while the earlier software could leave some of those edge cases up to the user.