Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bret Victor: Learnable Programming

worrydream.com

Post reply on HN
Print view View original

71–80 of 193 posts

Re: Bret Victor: Learnable Programming

#71

Post by Ygg2 »

gojomo wrote: post #63

Beautiful and inspirational, and yet... Sometimes becoming able to hold the 'invisible state' in memory is the skill to learn. Consider the 'dual N-back' drilling which seems to improve working memory, and then also (by some studies) other testable fluid intelligence. The whole point is holding more and more hidden state in your mind. (To 'show the state' would defeat the purpose of the game.) Similarly, sometimes st…

Having an environment such as one Victor styled for big systems (big as in millions of lines of code), would prove unfeasible (hell auto-complete has a hiccup when lines start getting into hundreds of thousands).

Those tools he proposes seem to be very beginner and RAD oriented (even if he claims otherwise). I've seen IDE's choke on smaller code bases and this not only has auto-complete, auto-update but also state/frame/time tracking built into. There is no way in hell it can work for existing languages. Maybe some kind of VM that remembers all it's previous states, all function call times, orders and then updates them as programmer changes them.

Re: Bret Victor: Learnable Programming

#72

Post by alid »

esperluette wrote: post #50
zmitri wrote: post #31

Cool demos, but very long article for what I thought he was trying to express. Bunch of thoughts, I enjoy thinking about this, so would love some conversation around any of the points: If programming is a way of thinking/problem solving, I'm not sure how supplying the context in line teaches you how to think -- as opposed to sitting down and figuring out a problem on your own. My experience has been that the best way…

I have to disagree ... there are a lot of folks who don't learn well being thrown in at the deep end of "mess around until you understand it", and for whom a Bretian visualization of data would be useful over and over again (especially for bugfinding). And what data needs to be visualized is different for different people; e.g., I can easily visualize most regex, but a lot of people love tools like Rubular because th…

As a newbie/wannabe programmer this completely resonates with me. It's not so much 'dumbing down' as about beginning with the end in mind and providing frameworks of thinking - it’s a lot easier to put the pieces of a puzzle together when you know what the picture is before you start.

Re: Bret Victor: Learnable Programming

#73

Post by dxbydt »

scott_s wrote: post #33

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 th…

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.

Re: Bret Victor: Learnable Programming

#74

Post by yaxu »

everlost wrote: post #36
bretthopper wrote: post #24

There's already two comments here about being "harsh" or "ungracious" towards Khan Academy which is ridiculous. The usual HN article that contains criticisms is usually limited to that. Some rant that took 10 minutes to write and contains nothing constructive. Bret Victor put an insane amount of time into this (I can only assume) and is truly advancing mindsets about programming tools and learning. We should all be t…

I agree. There is a lot of constructive criticism in the article, and I'm sure Khan Academy would love this kind of feedback to help improve the platform. Hell, even I learned a couple of syntax usages just watching videos of the learning interface!

He could have delivered the "this is something to build on" message without the "almost worthless" value judgement.

Re: Bret Victor: Learnable Programming

#75

Post by seanmcdirmid »

yaxu wrote: post #65
marcioaguiar wrote: post #58

Earlier quoted context omitted.

It's important to point out that was Bret Victor that created this concept from which Kahn Academy took inspiration from. https://vimeo.com/36579366 http://ejohn.org/blog/introducing-khan-cs/

As Bret Victor says in his essay, live coding is not a new concept and he did not create it. The current trend in live coding seems to have spawned from a discussion between two computer musicians (Fabrice Mogini and Julian Rohrhuber) in 2001, with masses of related prior art going back to Lisp machines, Self, Smalltalk, corewar etc.

Responsive live programming (not just code reload), which is closer to what Bret Victor is doing here, goes back to various visual languages of the 80s and 90s.

Re: Bret Victor: Learnable Programming

#77

Post by [deleted] »

yaxu wrote: post #54

Bret Victor is annoyed at his ideas being labelled live coding, but that's what they are. Live coding environments are pretty diverse, and there is plenty of prior art for code timeline scrubbing, tangible values, auto-completion, the manipulation of history, and many of the other features that Bret argues for. Some examples: Field - http://vimeo.com/3001412 SchemeBricks - http://blip.tv/nebogeo/dave-griffiths-chmod-…

[deleted]

Re: Bret Victor: Learnable Programming

#78

Post by mamcx »

andolanra wrote: post #51

As far as learning is concerned, I think this is a wonderful idea. I say this in part because I myself learned on Logo before I taught people everything from Java to Scheme, and even the simplest visualization tools could help immeasurably. For example, we had a tool called the Replacement Modeller that would visualize evaluation and substitution in pure-functional Scheme snippets, which was great for stepping throug…

I'm toying in build a new language (more in the "find ideas" than really doing it), and tough: Why I can't have events on functions? ie: Why I can't attach listener to the entry/exit of a function, in a transparent way (from https://gist.github.com/3777791, where is still ugly as hell):

def startDef: self.cache['start'] = now

def endDef: performance.register(self.function.__name,'time', now - self.cache['start'])

hook(sample,pre = startDef, post = endDef)

Now with that ability, is possible to log with a graph the flow of the data in the program, in realtime. Still will lack the instant play but is a good start...

Re: Bret Victor: Learnable Programming

#79

Post by jules »

This is really neat. It does paint a far too optimistic picture, however. The mini-IDEs that he presents are highly problem specific. That's great when you are teaching programming and you control exactly what the problem is and what the IDE does for that problem. But this is presented as a solution for programming in general (see the section "These are not training wheels", e.g. "Maybe we don't need a silver bullet. We just need to take off our blindfolds to see where we're firing.").

The control flow visualisation works great for toy problems when learning programming, but quickly breaks down in the real world. The iteration counts become too big to see anything. If you are working with functions that can be sensibly plotted when the iteration counts get too large that's great, but 99.9% of code is not like that. You're working with billions of seemingly random integers, or with strings, or even more complex data structures. How are you going to visualize that over time? Probably for each problem you can come up with an adequate mini-IDE, but that doesn't really help because implementing that mini-IDE is more work than solving the original problem in the first place. To make this practical you need general purpose tools with easily customisable visualisations (and IDE interactions in general).

Another example is the UI for the bouncing ball. Displaying the trajectory of the ball faded out like that works great for an animation or a very simple game where a single thing change over time, but how about a more complicated game where the entire screen changes every frame (as in most 3d games and even side scrollers). That's not even considering GUI applications!

This type of visualisation is also highly specific to single imperative loops, yet the author agues against that. How do you visualize a program structured functionally? You can try to do something with an unfolded expression tree, but that quickly gets out of hand too.

All the examples in the post fall into the category "drawing a very simple 2d scene with at most a singly nested loop". How big a subset of the field of programming is that? It's also no accident that the author chose that subset: it is the easiest case for this kind of visual interaction. Don't fall into the trap of extrapolating the results to all of programming, and thinking we are almost there and the problems lies just in implementing this kind of IDE. While this is superb work, 99% is still to be discovered.

Re: Bret Victor: Learnable Programming

#80

Post by thedudemabry »

th0ma5 wrote: post #13
aaronblohowiak wrote: post #4

Earlier quoted context omitted.

except the computer can and does run the code, and can then provide super-textual information

but is that helpful? i mean, i love lots of various reference sites, and have enjoyed autocomplete and inline "labeling" of functions in IDEs, but I keep thinking about his talk that went big a bit ago, and keep thinking of these things he's developing as just analytic or test harnesses to zero in on a goal that he's actually already programmed. so, to ask for our tools to have these qualities built in assumes it kno…

Regarding your fill() example, I believe his point was that uninformed decisions are a reflection of the interface exposed. Since the fill color is an implicit global variable, and not exposed anywhere in the interface, there is no way to discover its existence or behavior except via trial and error or reading the documentation. If the fill color were either exposed via the programming interface, or were explicit, then no meta-knowledge would be required to use it.

Similarly, the heap size limits in Java are global limits implicit to the system, not to the program being designed. His solution to the larger problem—data growing beyond available resources–might involve providing a better visualization of the data. Something more responsive than the feedback loop provided by heap limits. Getting an OutOfMemoryException doesn't help you to understand how the data grew beyond expectations; it is always followed by a heap dump. What if you could better understand the patterns of allocation during design instead?

Post reply on HN