

Why Programming Languages Are Hard To Teach [video] - dysoco
http://oredev.org/2012/sessions/its-not-you-its-them-why-programming-languages-are-hard-to-teach

======
nnq
...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.

~~~
quanticle
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?

~~~
nnq
...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]

~~~
quanticle
_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?

------
scotty79
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.

~~~
bad_user
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...](http://ocw.mit.edu/courses/electrical-engineering-and-computer-
science/6-001-structure-and-interpretation-of-computer-programs-
spring-2005/video-lectures/3a-henderson-escher-example/)

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

~~~
scotty79
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).

------
rartichoke
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.

------
wollw
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>

------
notb
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)

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

~~~
notb
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.

~~~
ufo
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"

------
scrrr
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. :)

~~~
blue1
"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_

~~~
arctangent
Also known as Rubber Duck Debugging:

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

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

~~~
quanticle
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?

