4 ms·
Programmers, by contrast, have traditionally worked in their heads, first imagining the details of a program, then laboriously coding them. I don't think this
by scott_s 14y ago
Programmers, by contrast, have traditionally worked in their heads, first imagining the details of a program, then laboriously coding them.
I don't think this describes most real work done by programmers. Rather, what he says we should do,
To enable the programmer to achieve increasingly complex feats of creativity, the environment must get the programmer out of her head, by providing an external imagination where the programmer can always be reacting to a work-in-progress.
Is exactly what most programmers already do. We usually don't have a nice, interactive environment to do so; it's usually a combination of coding, inspecting results, thinking some more about new issues, coding, inspecting results, on up until the problem is solved.
In other words, I think that programmers do tend to solve problems by "pushing paint around." I rarely start with a full appreciation of the problem. But in order to gain that understanding, I have to start trying to solve it, which means starting to write some code, and usually looking at results. As I go through this process, the domain of the problem comes into focus, and I understand better how to solve it.
We already do what Bret is talking about, but not at the granularity he is talking about it. For beginners, I can understand why this difference is important. But I certainly solve problems by pushing paint around.
In general, I think this is a fantastic piece for teaching programming, but I don't think (so far) that all of it carries over to experienced programmers. The examples of having an autocomplete interface that immediately shows icons of the pictures they can draw is great for people just learning. But that's too fine-grained for experienced programmers. Chess masters don't need to be shown the legal moves on a board for a bishop; their understanding of the problem is so innate at that point that they no longer play the game in such elementary terms. Similarly, experienced programmers develop an intuition for what is possible in their programming environment, and will solve problems at a higher level than "I need to draw something." That is the reason we put up with existing programming environments.
- alisey 14y agoAnd the more abstract your knowledge and understanding, the harder it becomes to visualize. It's relatively easy to visually explain classical mechanics, but not so for quantum mechanics.
- dxbydt 14y agoBret has written an amazing article, but the world he inhabits is soooooooooo far away I can't ever imagine getting there in my lifetime. As it stands, programming is barely 2-3 levels of abstraction above shoving bits in registers...sometimes even those few layers are slowing us down and we have to resort to bit shifting operators and native code every once in a while. Whereas he is talking about 20-30 layers of abstraction. He wants to visually depict code, and then visualize functions, visualize data structures, visualize the connections between functions, and actually visualize how the program is running while its running !!! Whereas the practical programmer of 2012 is still buried neck-deep in textual stack-traces.
- theatgrex 14y agoThis is what he is suggesting for learning to program. I don't think he is suggesting that general purpose programming languages be built with these aids ...only an idealized learning language
- klibertp 14y agoAs a counterexample to shoving bits I can point to two things mentioned by Bret: Morphic and Smalltalk. It just so happens that Morphic (referenced in it's original, Self implementation) was ported to/implemented in Smalltalk (Squeak, Pharo). These are things that exist and work today, I had a pleasure to work with them and have to say they live up to expectations. It's worth trying them out. Another curious example is Erlang, which lets you update the code responsible for some behavior (I mean of an object) live, without any hassle at all. Then there's ClojureScript, which lets you do the same in browser (I think, don't know it very well). Foundations of what Bret says are not new, and they are not purely theoretic either. The programmer of 2012 could have been using them for years if he wanted to. I think Bret is right when he writes that technical possibilities are not a problem - programmers mentality is. Both Lisp and Smalltalk programmers would welcome - I imagine - Bret ideas without a shred of hesitation, because they are working in a similar way since times immemorial. It's just that there are so few of them and Bret wants to influence programming at large - that's why it seems to be difficult or novel.