Yet, you could approach the problem from two other angles: 1. Imagine you have a reasonable library of primitives (say, library functions). And you build a pro

Yet, you could approach the problem from two other angles: 1. Imagine you have a reasonable library of primitives (say, library functions). And you build a program that does exactly what you want, but it's ugly, a hodge-podge mess of something written quickly together. No SW engineering rules followed. Then an automated process can refactor it, keeping the behavior the same, but making the program look much cleaner, or maybe even inventing new primitives (functions) along the way (if it sees the opportunity in your program or even across programs), in general, making the resulting program easier to understand, modify and work with. Then you can iterate on this process. (I have discussed this at https://news.ycombinator.com/item?id=13820070 https://news.ycombinator.com/item?id=13820070) 2. We could limit computers to a total language, which would describe some basic operations on non-recursive tree-like data structures. Then given some examples of transformations between those data structures, a computer could automatically infer a good description (from some building blocks) of the transformation that satisfies most of the examples. Since lot of today's programming is transformation of such data structures, it could greatly save time. This is similar to machine learning, but the goal is to have a succinct, understandable explanation of the transformation.