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

91–100 of 193 posts

Re: Bret Victor: Learnable Programming

#91

Post by klibertp »

dxbydt wrote: post #73
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 abs…

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.

Re: Bret Victor: Learnable Programming

#92

Post by klibertp »

macrael wrote: post #88
theatgrex wrote: post #83

Earlier quoted context omitted.

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.

Re: Bret Victor: Learnable Programming

#93

Post by skybrian »

This article is quite thought-provoking. However, I disagree with the notion that there's something wrong with "unlabeled" programs outside a learning environment. To learn a language, you need to associate unfamiliar words with concepts. A text written in French isn't broken because the words aren't all labelled with their English translations, much as that might be a nice UI for people learning the language. Nor do you think in a language by translating each word into English first.

We do a lot of programming using API's we're not yet fluent in (and may never be), and that's why IDE's can be so helpful and this isn't black and white. But at some point you do need to get some core concepts into your head and communicate them in a reasonably terse language.

Re: Bret Victor: Learnable Programming

#94

Post by stephth »

dxbydt wrote: post #73
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 abs…

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.

Re: Bret Victor: Learnable Programming

#95

Post by seanmcdirmid »

yaxu wrote: post #89
seanmcdirmid wrote: post #75

Earlier quoted context omitted.

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.

Like the ones I mentioned.

You didn't mention any VPLs. I would throw in a few...ThingLab, AgentSheets, LabView, Prograph, Fabrik, and so on. These were the original live languages.

Re: Bret Victor: Learnable Programming

#96

Post by kennywinker »

ChuckMcM wrote: post #57

I really enjoyed Bret's article. I don't necessarily agree with all of it but the main argument is quite sound. Bret writes: "People understand what they can see." which is true for some people but not true for all people. I've got one daughter who is very verbal, one very visual. They learn differently. This in a minor nit though, his exploration of the 'code' / 'example' model is good. I particularly liked the comm…

The problem with making the "training wheels" optional, is people will leave them off. All of a sudden your code is not useful or readable to anyone unfamiliar with your code. Even yourself. Sure you might know what the parameters in `ellipse 60 50 50 100` do right now, but what if you haven't worked on drawing code for 6 months?

It seems to me like what he's talking about is less a bicycle with training wheels than it is a self-balancing segway. A bicycle with training wheels is annoying to anyone but a beginner... what he's talking about is something that isn't annoying to a pro... even if they don't lean on it as much.

Re: Bret Victor: Learnable Programming

#97

Post by Evbn »

mamcx wrote: post #78
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']) ho…

"Aspect Oriented Programming"

Re: Bret Victor: Learnable Programming

#98

Post by seanmcdirmid »

Ygg2 wrote: post #71
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/fr…

We just need to design better IDEs and languages. Ya, large code bases suck but not that much. We can actually compile code pretty quickly, and we are only just beginning to study memoization techniques (which you are alluding to at the end of your post). Also, language is a very big deal: you can't really expect as much from the IDE on C++ as you can from C#.

It can scale, we have plenty of smart people to make it scale. The important problem here is "scale what?" I think that is the genius of Bret Victor's innovations.

Re: Bret Victor: Learnable Programming

#99

Post by Evbn »

aaronblohowiak wrote: post #3

This is a fascinating response to the Khan academy's curriculum. Some of the things he is raising here are faults of programming languages; I'm still against the idea of positional parameters. Khan Academy's curriculum is Android to Brett's iOS: you can copy some of the features, but it isn't a cohesive whole because the ideology was not as thoroughly internalized.

That isn't fair. Khan implemented a working system, compared to a vague idea.

Re: Bret Victor: Learnable Programming

#100

Post by theatgrex »

macrael wrote: post #88
theatgrex wrote: post #83

Earlier quoted context omitted.

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.

Oh yeah you are right, my mistake!
Post reply on HN