Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

It seems they make the same mistake as the Khan Academy computer science editor [1] does. Bret says something about it in his learnable programming [2] post:

> The programming environment exhibits the same ruthless abbreviation as this hypothetical cooking show. We see code on the left and a result on the right, but it's the steps in between which matter most. The computer traces a path through the code, looping around loops and calling into functions, updating variables and incrementally building up the output. We see none of this.

I mean, this is a nice start, but we still have lots of work to do before we really understand what we are doing in this area.

[1] http://ejohn.org/blog/introducing-khan-cs/

[2] http://worrydream.com/LearnableProgramming/

View on HN

That's right, and I hope that's where both Tributary and programming in general are headed. However, saying that they "make the same mistake" seems odd. Progress can happen incrementally, and sometimes you have to see what works and what not. It's almost as if you have to prototype your idea and see real results immediately, very similar to the goals of learnable programming.

You are right of course; the problem is that even though there have been people working on this problem since 2003, no one has communicated very well about the results outside of a few academic circles.

Hancock solves this problem with live text in Flogo II, but all we know about it is from his dissertation (http://llk.media.mit.edu/papers/ch-phd.pdf). I observed the same phenomena when I did my Sueperglue work back in 2007 (http://research.microsoft.com/apps/pubs/default.aspx?id=1793...), but I never really bothered to follow up until now (with inspiration from Bret's work, of course).

Seriously, the ability to "step through" a program is HUGELY helpful for learning what programming does. I remember learning the beginnings of programming in Visual Basic for Applications inside Excel 2003. The best feature was the ability to "walk through" the program, with a yellow line highlighting the current code being executed and a window that showed all the variables and their outputs in a highly readable format. Those two things really helped me as a kid learn what programming looked like.

It is both a very nice start, and there is definitely lots of room for improvement.

I'm working in this very area too.

One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program (the tool should do everything it can to make the process easy, you just supply the necessary inputs).

> One other thing I can add is that, IMO, it's very valuable to be able to easily execute a subset of the entire program

Sounds sort of like Bracha's stance.

I think we should just focus on making the feedback better over an entire program execution. And we could make defining unit tests easy, which would provide the context needed to test smaller parts of the program.

Could you please link me to what you mean by Bracha's stance?

I think making feedback better over the entire program execution is hard when dealing with immensely large projects. But breaking down those huge projects into smaller pure components with well defined dependencies might stand a better chance. I don't know for sure yet, but I'm gonna try and find out.

I just saw him speak about it at a meeting we had recently. He also has something about this on his blog (http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode....), though I don't think he says anything about that there.

I'm trying to write a paper about this right now for Onward, but I think its possible to do large programs with the right amount of incrementalization within. There is definitely a limit though (if the change influences a lot of stuff, there isn't much we can do right?)

Thanks, that was an excellent read.

i'm wondering if we can first explictly state the objective by which this is being judged, mistakes or successes assigned

What is the goal and how effective is the technique in realizing the goal. Bret's work is nice because he so clearly articulates the goal.

Reply on news.ycombinator.com