Talks by Alan Kay are always fun. In this one he talks about inherent vs incidental complexity of software systems.
It turns out back in the day there wasn’t much of a distinction between hardware and software engineer. Instead of software or hardware engineer there was just one kind of engineer, the system engineer. The system engineer would think about the problem that was being solved, design a problem-oriented language to encode the problem, and then implement a system to interpret the problem-oriented language to solve it.
It doesn’t take a genius to see why a system-oriented approach to solving problems leads to less incidental complexity. When the entire pipeline is designed with the intent of solving a specific problem there isn’t much room to add incidental cruft. Some incidental complexity will still creep in because we almost never have complete understanding but at least the understanding gained along the way can be fed back into designing a more focused and cleaner system. Contrast that with the modern approach where hardware and software designers just do stuff with complete disregard for what is happening in the other camp and it again doesn’t take a genius to see how the modern setup can lead to impedance mismatches that can only be resolved with unnecessary cruft.
In the linked video one of Alan Kay’s students talks about the problems that were encountered along the way when translating Nile (the graphics layout language) into SIMD instructions for efficient execution. But even if you are not thinking about problem-oriented languages and just looking at the modern software stack you don’t have to look far and deep to see all the unnecessary accumulated cruft. How much of the modern OS do you really need to run a JVM application?