Why Programming Languages Are Hard To Teach [video] | Hacker News Reader

Why Programming Languages Are Hard To Teach [video]

oredev.org

81 pointsdysoco22 comments

...I think that a lot of teachers for get that the hardest part in teaching someone how to program is: MOTIVATION, motherfucker

people can learn anything up to a certain level if they WANT to do it, and most people need short reward feedback loops like 'do smth' and 5min later 'tadaam! cool result!'. I think the simple fact of 'seeing cool results' is the main value of using drawing when learning people how to program. Kids and people in general are used to GUIs and cool graphics everywhere and text is boooring to them and associated to boooring schoolwork, so graphics seems the only way to give beginners this simple feedback loop (music will probably work, but for a smaller number of people), and the fact that it might pool them towards geometry and later some cool math that can be visually explored through programming seems like a good side effect. Actually I like the idea of using programming as a platform for teaching math and these silly looking programming drawings seem like the best launchpad for something like this.

That's not true. Do you expect someone to play the opening bars to "Stairway to Heaven" after 5 minutes with a guitar? Heck, do you even expect them to play a scale? And yet, does that stop people from learning to play guitar?

Moreover, going back to the point that Zed repeatedly hammered home in that presentation, do you have any evidence that this is actually what stops people from learning programming?

...ok, you convinced me to start looking ...the evidence to look for would in this case be studies that compare drop-out rates for courses using visually "augmented" total beginners programming classes vs "classic" ones for the same target ...a quick search on google scholar dind't help, but I'll retry with different keywords later in the day when I'll have some time

...if you happen to know of any such study that either approves or disproves my "intuition" please tel. on the side I happen to like Zed's "learn X the hard way" since the first language I learned was C and I too started by typing code I dind't understand at first... but I always found that the people around me were never as motivated as I was they never seemed to feel "the rewards" part of having you program running so I assume that it was because for them it was just text on a screen and this simply didn't give them the "spark" to carry on and I imagine graphics have more "spark" potential, but yeah, a spark doesn't guarantee the engine will keep on running or that they will go into the right direction...

[EDIT+: I dunno about his music analogies as I can't say I "get them" at all as I really don't get music, I never even tried to play an instrument and I'm mostly "tone deaf" and for me music is something that I just "viscerally" like or dislike, I don't even try to understand it so I totally can't relate to this area... but I can draw and do graphic design and I sometimes even find it easy to imagine equations for rough sketches of drawn shapes that I'm looking at]

I dunno about his music analogies as I can't say I "get them" at all as I really don't get music, I never even tried to play an instrument and I'm mostly "tone deaf" and for me music is something that I just "viscerally" like or dislike, I don't even try to understand it...

That is exactly how a large proportion of people feels about programming. "I don't know about programming; I can't say that I "get it"; I've never tried to write code [...] programs are things that I just "viscerally" like or dislike."

I think that there is definitely room for study here. What sorts of things do music instructors, for example, know about keeping beginner students motivated enough to keep practicing? Can we bring over some of those ideas to programming instruction?

> does that stop people from learning to play guitar?

It stops some people who thought playing guitar is enjoyable and when they actually try and see that it's not, they stop before they learn anything that some day might turn playing guitar into enjoyable activity.

Some support for your thesis:

Alice[2] is a graphical environment to teach programming. They did a study of it for high risk CS1 students and found that high risk students who used Alice achieved a much higher retention rate[2].

[1]http://www.alice.org/publications/EvaluatingTheEffectiveness...

[2]http://www.alice.org

Zed Shaw doesn't seem to like mixing coding with its visual effect but that's how most of small to medium webdevelopment is. You make some changes in the code, refresh the page and see if that did what you wanted it to do.

Victor and Resig do the same thing, sans Alt+TAB, F5. And yes, I keep my code editor on the left and browser on the right and have no idea why.

I'd love to see more visual tools for programming. Not for designing stuff, or building algorithms out of bricks but rather inspecting what a mess I'm making.

Currently most advanced commonly used visual inspection tool for assessing whether you are ankle deep or knee deep or deeper is directory tree of your project.

One can argue that visual tools are only useful if you're building with a top-down approach.

Visual tools can help here, because developers take shortcuts and you’re never developing in the perfect case, so you often end up with coupling that shouldn't be there, which creates extra complexity and in general, a "mess".

On the other hand, you can take a "bottom-up" approach to building stuff, in which you're you're building layer upon layer, such that top layers depend on bottom layers, but never the other way around. You do this by designing for each layer a domain specific language for that layer, which layers at the top can use [1] [2].

And visual tools don't really help in such a case, but on the other hand visual tools aren't really needed. In my opinion visual tools for software development (and I'm thinking primarily of UML here) are just fixing a symptom instead of the real disease, giving you a wider window for building a mess.

[1] http://ocw.mit.edu/courses/electrical-engineering-and-comput...

[2] it can be argued that Unix was built like this

Bottom up is really great when you know what you want to achieve, but in some areas, like game development - You don't know what you want to make until you make it. It demands quick iteration and evaluation. In such environment it's great to use top-down.

I'm not talking about UML or anything similar or designing or building. I'm talking about visual inspection tool for my code. Something like code-to-UML not the other way around that shows components and their actual interactions (of course UML is not expressive enough to display all situations encountered "in the wild" and it was designed for paper so it should be something else).

Scratch is one of the visual tools he spoke about.

I'm not sure how he can bash such a tool. When you're such a beginner that you don't know what a semi-colon is then scratch is the EXACT tool you want to teach with.

It allows people to get to the logic and interesting problem solving mechanics of programming instead of worrying about including header files or curly braces.

All you do is drag/connect constructs together and you can instantly see the results.

I'm not sure why but the video wasn't showing up on that page for me. Here's the Vimeo page: http://vimeo.com/53062800

Zed has got it twisted. Khan Academy's environment was 'inspired' by Victor's 'Inventing on Principle' talk which encompassed much more than what's discussed here. Resig did not implement Victor's 'Learnable Programming' article, because the article was, in fact, a response to the Khan Academy implementation. I imagine Victor built upon Resig's work to make those little demos in the article. Victor explicitly states JavaScript is a poor educational language, and the demos are just the simplest examples of his principles, by extending the Khan Academy model. [1]

[1] http://worrydream.com/LearnableProgramming/ (the bottom)

I don't think much of Victor's work is built upon Resig's, mostly the other way around.

You aren't following me. 'Learnable Progamming' is 'built on' Khan Academy in that it is a response to it and it works from the JavaScript/Processing environment that Khan Academy put out. There are obviously questionable assumptions being made about it being a good environment in the first place, but it is simply used to make a point. Zed makes some straw man arguments by conflating these concepts.

From what I remember, Bret originally said some things about teaching programming with this visual interactive stuff, resig&khan academy went and actually implemented something, saying that it was inspired by Bret and then Bret wrote his big post saying that what resig & khan academy did wasn't quite what we had in mind.

When I saw the talk I understood it as more of "resig implemented the interactive paradigm" then "resig implemented the things in learnable programming"

There's some interesting things in this talk. Like finding bugs by reading code backwards.

I find 99% of my bugs when I ask a colleague to help me find it and start explaining to him what I am trying to accomplish with my code. It just makes me see the bug. And makes the colleague that interrupted his work wonder why I asked him to come over. :)

"One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor." — Kernighan/Pike, The practice of Programming

Also known as Rubber Duck Debugging:

http://en.wikipedia.org/wiki/Rubber_duck_debugging

It was really interesting seeing how many people didn't spot the bug first time, and even reading backwards had issues finding it. (don't know if this is visible on the video)

Watching my teenager child learn to code I could certainly see some of the issues Zed talked about.

Because programming is hard to teach. Because abstract thinking is hard to teach.

Great cop out answer. "Teaching programming is hard; let's go shopping." Why is it hard? What rough edges can we sand down so that the only difficulties are essential ones, not incidental ones?

Stepping back even farther, how do we even know that programming is hard to teach?

Reply on news.ycombinator.com