Comment by scott_s | Hacker News Reader

Comment by scott_s | Hacker News Reader

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.

Bret 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.

This 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

Read the end of the article. He definitely thinks this is the future of programming.

Well, it certainly is the past, I see no problem with it becoming the future. At last.

Oh yeah you are right, my mistake!

As 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.

Bret has written an amazing article, but the world he inhabits is soooooooooo far away I can't ever imagine getting there in my lifetime.

True, he doesn't seem afraid to take big leaps. Brilliant, visionary essay. But I don't think it's unrealistic. In my day to day (game dev) I spent very little time optimizing (and very rarely need to write any sort of bit shifting), but instead a huge chunk of development is spent slingshotting variables through loops into abstracted rendering directives. The hardest part in my job is by far understanding and visualizing program flows in my head. From the essay:

Wait. Wait a minute. Were you trying to answer those questions by doing arithmetic in your head? The computer somehow drew that picture, so the computer must have calculated all those scaleFactors itself. Are you seriously recalculating them in your head?

Sadly, yes, very often I am. Depending on the mood I also use a convoluted combination of notebook + pencil, breakpoints, printf statements, and/or isolating the problem by working on a separate program with the problem simplified. And having aids - like some of the great solutions suggested like the timeline and other state/flow displays - would give me tremendous gain today, if they could be integrated in my toolset. I'll give you that I imagine it being quite a bit more challenging technically to make it work with my C/C++/Objective-C environment, but with other more dynamic languages - like Javascript or as suggested: Clojure - I imagine it to be much easier.

This article is by the way, most likely the best argument I've heard so far for me to move to a higher level language. I like how Bret Victor talks about language (and API - see the autocomplete argument) choices as enablers to better environments; I think we instead usually think of language choice as something that mitigates how hard this work is to begin with with the tools we have (see the time and energy we spend in in this community on language choice). If I had access to tools offering this level of abstraction but had to adopt a language that I didn't particularly like, I think the latter would then become be the least of my concerns.

I don't think that Bret is advocating that this is the way all programming should be. That would be strictly impossible, as some functions have totally non-linear effects on their output, so you couldn't easily connect one to the other with handy arrows and highlighted stuff.

The geometry example is chosen because it's easy to make a mapping between the space of function inputs and visual outputs. And each parameter is independent of each other.

Khan Academy has already implemented some of this for JavaScript, running right in the browser.

http://www.khanacademy.org/cs/drawing-bonus-rotation/9064481...

Try clicking on the coloration functions to see previews, or sweeping with the mouse to change the values.

As for the more advanced features, many languages exist today which make this quite possible, at least for teaching tools. Even well-commented Java has the kind of typing and documentation culture that would allow you to implement a lot of this today.

Java's documentation, while allowing to document each parameter, still doesn't make the actual result of changing a parameter obvious to a program.

In Bret's video, where hovering over a parameter would show what exactly would change – that requires either machine-readable metadata (i.e. x position of top-left corner of the shape) or additional programming to make available. Javadoc as it exists is just a semi-structured and very thin wrapper around HTML. Not really much a computer could do anything with.

The general problem I see with Bret's approach, while it works very well for restricted programming environments intended for beginners and learners, it falls short for more complex things. But then again, those of us who know half the language framework by heart anyway won't probably need as much guidance or fiddling around. Still, it requires augmenting each and every function with a piece of visualisation code or enough metadata so a development environment can apply the visualisation itself.

he's suggesting we as tech startup entrepreneur type guys go out and imagine the actual solutions that can work across a number of problems based on the examples he's provided.

I'm absolutely so surprised by the lack of imagination here at HN. This is startup ideas gold right here, and none of you seem to have the mental capabilities to dig it out and do something with it. You all want to find something wrong with it.

Ever since I've been tracking Bret Victor, my head has been spinning with tons of practical ideas we can implement today to make us more productive at programming. Light Table is a fantastic start. What's the problem here, guys! You guys just don't want to admit the way you've been coding thus far will soon be obsolete and you've been wasting your time. Yes, your skills will eventually be worthless.

And 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.

Reply on news.ycombinator.com