I think the fundamental issue that makes programming hard, and harder with time, is that we don't describe goals, we describe steps towards a goal. The computer

I think the fundamental issue that makes programming hard, and harder with time, is that we don't describe goals, we describe steps towards a goal. The computer only understands how to move through the state space, it does not understand where to go. We end up reverse engineering the goal / end result into the series of steps / state transitions needed to get there, and we call this activity programming. The core problem there is two-fold. One, humans are bad at breaking things down explicitly into steps, and we make errors of description and errors of omission, which we call bugs. The program arrives at a goal, it is just the wrong one. Second, that goals grow more ambitious with time. At one point making a basic spreadsheet was a major endeavour, now it is a practical exercise as part of a programming course. Because the goal is more complex / further away, the number of steps required grows bigger. The current focus of tooling is in ways to make it easier to describe the steps, by giving you starting points closer to the goal (frameworks and blueprints) or by making the steps bigger (languages, libraries and abstractions) or by agreeing on patterns of steps, etc... I think this line of thinking, while important, is inherently limited in its ability to solve the problem. Fundamentally, the trick to making programming easy is to turn it into something goal-oriented instead of step-oriented. You describe the desired results and the computer works out all steps regardless of the state space, and adapts as the state space changes (new data, changing circumstances). Basically this is what unit tests do, minus the part of programming the code behind the test. But imagine one person writes only tests, and one writes only code. Replace the second person by an algorithm, and tada, goal-oriented programming. That part looks solvable to me. But ... now the problem becomes one of describing the goal, and we're merely shifting piles around in the problem space. Someone who cracks the problem of easily and accurately describing a goal would solve the harder half of the problem. Anyway, just my two cents.