Live data from Hacker News

Bret Victor: Learnable Programming

worrydream.com

41–50 of 193 posts

Re: Bret Victor: Learnable Programming

#41
post #29

Its a smartly written piece, but to me this just scratches the surface. A couple of issues: 1. If you are making the conceptual jump from 'text' to 'dynamically annotated text', why not go a step further and just let people draw a rectangle with visual tools entirely (like in Illustrator,Inkscape,etc.) and forget the textual representation? 2. The real difficulty comes with representing things as they may arise throu…

1)He shows an example of this. The last one in http://worrydream.com/LearnableProgramming/#react 2)I think the examples with the various timelines, wrapping code in functions or for loops, and replacing constants with variables came a long way in that direction

Thanks. I'd missed the first one.

The timelines are good, but what I mean by 'dynamic' is something with user input that affects objects. Its easy to show how a loop can draw the same shape in lots of different ways, but what happens if the loop might draw different things depending on what the user inputs while the program is running? This gets tricky.

Re: Bret Victor: Learnable Programming

#42

As far as labeling function arguments, I've always used an IDE that supports some kind-of feature that gives me exactly that. In Eclipse, Java (JDT), C/C++ (CDT), Python (PyDev), Go (Goclipse) -- all support the little pop-up box that appears when you type the name of a function and shows docs related to that function. This feature is so crucial, I couldn't use a development environment without it.

He mentions the context being needed for a function call, more than once -- it makes me wonder, doesn't anyone use IDEs? (I don't know vim/emacs are so popular when they provide no context - much more crucial to me than editing power. There's a plug-in for vim that uses ctags to provide context, I hear, but I don't know of many that use it :/)

They do not, by default. I guess the issue here is that we have too many different environments, so it would be impractical.

If you do take some effort, you end up with something like:

http://emacsrocks.com/e11.html

Re: Bret Victor: Learnable Programming

#43
His interactive demonstrations almost feel like he is reinventing Excel. And i like it.

This kind of symbiose between IDE and program code isnt just usefull for teaching, nor large scale software development....

It seems extremely usefull for "explorations" of data. There is a brilliant application idea hiding behind these ideas.

Re: Bret Victor: Learnable Programming

#45
Back in the 80's, when you turned your computer on, you were thrown into a programming environment (usually Basic).

I started learning to program at age 8, I just had no idea that the thing I was doing even had a name - I just typed commands and the computer responded (no compile, link, run steps).

Took me a while to figure out what the 'for' did (I was drawing grids one line at a time). I still remember what it felt when I finally figured it out.

An educational programming environment should be installed in every machine. You never know who's going to get interested on it.

Re: Bret Victor: Learnable Programming

#46
post #27

Earlier quoted context omitted.

1)Because that is not learning programming, which is entirely what this essay is about. 1.b) Learning programming is about learning to reason about problems. Not about learning to use different tools. 2) I think I agree that dynamic programs would be more challenging to do this with. On the flip side, this demonstration is so far beyond my reasoning that it doesn't mean much to me. It's all stunning.

1: That is not entirely what he's saying though: A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change. Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow…

True. I mistakenly thought I had reached the bottom of his essay when I hadn't.

Re: Bret Victor: Learnable Programming

#47
post #27

Earlier quoted context omitted.

1)Because that is not learning programming, which is entirely what this essay is about. 1.b) Learning programming is about learning to reason about problems. Not about learning to use different tools. 2) I think I agree that dynamic programs would be more challenging to do this with. On the flip side, this demonstration is so far beyond my reasoning that it doesn't mean much to me. It's all stunning.

1: That is not entirely what he's saying though: A frequent question about the sort of techniques presented here is, "How does this scale to real-world programming?" This is somewhat like asking how the internal combustion engine will benefit horses. The question assumes the wrong kind of change. Here is a more useful attitude: Programming has to work like this. Programmers must be able to read the vocabulary, follow…

Thanks. This was my reading of the OP also and what I was responding to (its about changing programming paradigms for everyone, not just about learning for beginners). I've edited my above post to reflect this.

Re: Bret Victor: Learnable Programming

#48
I think this article raises some brilliant points, and is very well written, but I also feel that it falls short of the mark Bret was aiming for.

As he himself alludes to, most of what he is teach is not programming - it is individual actions. Just as being taught the meaning of individual words does not teach you to write, being taught what certain functions or statements do does not teach you to program.

What is important is not spelling, but grammar - the shape of a program. His parts on Loops and Functions are better on this - the timeline showing loop instruction order is pretty awesome. However, it's still not perfect. At no point is the user instructed what a 'function' is, and how to use it. How do they know that they should be using it? I agree with other commentators who have suggested that it looks too much like he knows what he is aiming for, and the tool is designed to aid that.

In fact, my strongest criticism is in regards to his rebuttal to Alan Perlis:

> Alan Perlis wrote, "To understand a program, you must become both the machine and the program." This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.

I'm sorry Bret, but Alan is right. You do need to be able to think like a machine. Not necessarily an x86 machine, but an abstract turing machine, or a state machine, or a lambda calculus machine. If you cannot think like the machine, you cannot outwit the machine. This is incredible important if you are relying on the machine to give you feedback on what the system is doing.

In all his examples, very simple things happen, and never go wrong more than drawing in the wrong place. What happens if he starts causing an infinite loop? Or creates cycles in a linked list (and remember, sometimes he may in fact want cycles).

In "Godel, Escher, Bach", Douglas Hofstadter suggests that one of the key ingredients for intelligence is being able to go 'up' a level of abstraction. Bret's comment about a circle being made up of small steps, and hence integrating over a differential function, is part of it. A human can recognise that sequential steps with a consistently changing angle can be viewed as a circle. A human can realise that certain relationships are iterative, recursive, self-referential, in a way that (currently) a computer cannot. This is what needs to be taught, and I fear that what Bret has shown here would not help in that element.

However, it's still going to be a better intro than anything we have currently, so I think that in regards to getting people to dip in and try, it will be a vast help. I just hope that Bret keeps thinking about bridging the chasm between setting down series' of instructions, and programming.

Re: Bret Victor: Learnable Programming

#49
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…

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.

Re: Bret Victor: Learnable Programming

#50
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 they can't. But I have a lot of trouble intuitively understanding functions like the graphical ones in Bret's examples.

As to "dumbing it down", I think programming can definitely have mass appeal, but there's a lot of "I had to learn closures uphill in the snow both ways" going on among seasoned programmers -- in the same way that current medical doctors often valorize their hours and hours of being on call as residents. A trial by fire may seem useful but in the end you just get a lot of burned people. But unlike MDs, there's no protective guild for programmers ...

Post reply on HN