What is Hard?
The question "what is hard, and what is not?" is itself hard. There's a subject, and a task that the subject has to do. You should find out whether the subject will find it hard to do the task. With some inputs of task and a subject, it is easy to answer. A misologist is on average capable of doing the same tasks as what a stone can do, but everybody is able to grab a coffee cup. The things the subject just learned are also usually easy for him.
This is an interesting question for toolcrafters, and programmers. Toolcrafters are naturally interested about how difficult their tools are to use. In other hand, programmers find themselves being the subject of the question. You can't remember everything about every program you ever created, but you are expected to maintain them. How hard it is for you to pick an old project up again? It depends on how well you prepared for the time of reintroduction. What is important to you and what will you discover rapidly without help? There's also no point to re-learn some things about the project, which things can you forget?
Programmers must perfect the ability to learn. While I'm writing this blog entry, there are 6 different source code projects I've been working with during the last week. There's simply no way to remember every detail anymore. I have to leave everything represented in a way that I can easily pick it up again when a need arises.
Making programming easier is a recurring topic. Bret Victor popular talks are about making program state opaque to the eye by visualizing it. Observing program state is something hackers have been doing as long as there's been systems to hack into. It seems very difficult as there's not a single system to visualize programs that would be sufficient and every program needs specific visualizers.
Beginner WebGL tutorials have concentrated on rendering simple, stationary colorful polygons. They're the same tutorials I used 15 years ago. To get aesthetically well working works of 3D there's lot more to learn. Something needs to be known about art and visual design, as one is involved to paint with triangles. You have to understand mathematics related to geometry to draw anything at all. Oh and to program the effects you starve for, you need the ability to understand, observe and deduce new things about things you already know.
Everything has it's intrinsic difficulty, one that is left when you remove the unnecessary. Major mass of population might not be able to learn programming even if they wanted to. You need the 130 IQ to do this. Though, it's not a bad idea to remove the unnecessary or master the skill to teach.
Bret Victor is talking complete bullshit on one thing, and it is a single phrase I end up remembering from him:
A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is a reasonable question, but it's somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change.
If they key to making programming easier is in illuminating what happens when program is running, we're talking about debuggers and tracers. The simplest kind of tracer you have is the print -command. I tend to use it often to figure out what my program is doing. There are people saying that strace is good way to figure out what a program is doing. It's the same idea after all as in the visualizers that Bret is popularizing. These ideas already exist in real-world programming, if you consider python programming real-world.
Bret is right on many things but he seems to have missed that excellent programmers are already taking leverage of what he's promoting. Acknowledging that might lead somewhere that can be taken into practice immediately, maybe there's something we could do for our tracing and debugging tools?