People seem to think the difficulty in coding is the mechanical act of writing code. "If only you could draw code!", they cry, linking together a series of blocks to represent program flow. The thing is, even if you make a language where it's impossible to fail (every program does something, it's visually intuitive when a program isn't valid), it still doesn't necessarily do <i>the right thing</i>.<p>The difficulty in programming isn't the mechanical act of writing code; we have copy-paste for that. The problem is having a mental model of the program execution, and mapping it to the real-world problem. This is the difference between good and bad programmers, and it applies to the population at large.<p>Case in point: I'm working with some soon-to-be grads from a CS program. In Java, one of them instantiated a class, and set an attribute of that instance. Elsewhere they instantiated a new instance, and tried to read the value back. And they couldn't understand why the value wasn't set, Portal-style, in their new instance. This guy, who has been in school for 4 years for CS, also couldn't figure out why it made sense to make specific shapes (circle, square, triangle) children of an abstract Shape class. He could, very easily, add a Search bar to an Android app because he had seen a tutorial on how to do it - but making the bar do anything was a tremendous feat, because it wasn't just the mechanical repetition of some pattern.<p>Even with experienced (>5 years) programmers, I've seen some really terrible debugging where it was clear the person didn't have a mental model of the code. They never really got any benefit from GDB, because when they looked at the internal state of the program they just shrugged and said "Yeah, looks right". And they owned the codebase. This was their code, and they couldn't reason about it.<p>After all that ranting, my point is: you can make it easier to write <i>some</i> program, but you can't make it (appreciably) easier to write the program that you need.