Hacker News Reader

Comment by angelbob | Hacker News Reader

Zed, you're awesome. With that said -- it's who you're teaching that lets you say this.

Right now there are people who know they want to learn programming coming hell or high water, and you do a damn fine job teaching them.

There are also a whole lot of people who might want to write apps, but do not want to go through the pain of learning programming.

The audience of Scratch, from MIT, is the narrow end of this giant wedge of people. They have nowhere to go from there because nobody else does it that way.

I miss the Apple II. It actually had a few on-ramps for people like that. Those on-ramps are pretty much dead now, though I have no idea why.

The guy writing this article isn't aiming at your set of programmers. He's aiming at all the people who aren't programming but would love to be able to build apps of one kind or another. There are a lot of them, and even a lot who could, and who we do a terrible job of teaching.

View on HN

And no, I'm saying it's a huge myth that nobody wants to learn the "hard stuff". They do, you just have to teach it right. After that you just have people who aren't interested in programming at all and no amount of graphics, games, or cute cartoons is going to make them want to. You can't force or trick enlightenment on people.

But more importantly, I have evidence to back my beliefs. This article has absolutely no evidence.

Hi Zed, I'm Al, the author of article. I'll admit the title is hyperbole. There are people who want to learn programming for the sake of programming, just like there are people who like learning math even though they don't see immediate practical applications.

I teach programming to a tiny class of 10-12 year olds on Saturday mornings, and have taught a couple one-off classes at Stanford's Splash program to a classes of a dozen students. I've found that having an end-goal in mind of what they will create is a much better hook than just explaining what for loops are (or the idiosyncrasies of the languages are, which Python & Ruby are good about keeping to a minimum.)

I don't think graphics and cute cartoons are needed to make programming engaging either. My book "Invent with Python" has games that use ascii text up until the last few chapters. There's a pretty low standard for games/programs that are cool enough to show off to other people, but nobody ever shows off code snippets.

I think the best thing about "Learn Python the Hard Way" over a book like O'Reilly's "Learning Python" is that your book cuts it down to the bare concepts: "Type this. This should appear. This is what is happening." That's great compared to most computer books where there are paragraphs upon paragraphs that could be whittled down to a single sentence or cut out entirely. "Learn Python the Hard Way" is barely over 200 pages. That's much more digestible than some 600 page tome.

I just think that many classes where the students aren't CS majors or necessarily dedicated to learning programming forget that it's not just the concepts that people want to learn but what they can make using those concepts. Small games and web apps are great for that. Like in Exercise 22 of your book says, "It’s important when you are doing a boring mindless memorization exercise like this to know why. It helps you focus on a goal and know the purpose of all your efforts."

I'm in the process of self teaching myself to program (I'm a civil engineering student). I discovered one of pg's articles somehow and gradually worked my way through them and began to think that I should probably learn to program myself. I have ideas for things that I presume could be solved though programming but without learning to program it is impossible to know what is possible, this is the hardest gap to cross.

I bought Zelle's Python book, started JavaScript with Code Academy, got Graham's ANSI Common Lisp out the library and tried Rails for Zombies but none really got me interested enough to stick at it.

Dan Nguyen's Bastards Book of Ruby however has been the most successful. It's pretty much straight in, actively encourages copying and pasting code early on, with the immediate prospect of making real programs which interact with the wider world (HTML scraping) instead of feeling isolated on your own computer. I could immediately how HTML scraping could be useful for someone and how the first short programs might be extended.

There are some excellent motivating articles as well which were really key in sucking me in. He also calls his type of programming 'data programming' which to me, a non-programmer who hasn't had the chance to be brainwashed by programming theories, is the most obvious name in the world - all these problems I think could be solved with programming are just manipulating data.

btw: I don't find the prospect learning to program games motivating at all; there seems to be so little you can learn from most of them and a dangerous waste of time.

Right, but I think you are confusing causation with correlation. You say, "Nobody wants to learn the boring stuff and they just want to make games." But, they will learn the boring stuff if you teach it right. The concepts aren't what's putting people off, they're just correlated with bad styles of teaching it.

For example, explaining programming to total beginners doesn't work. Like you say, paragraph on paragraph about boolean logic is pointless if they can't even type:

print "hello world"

A beginner can't understand this because they don't have the cognitive tools to comprehend your explanation. But, if you make them do it a bunch, in tiny bites, and build their understanding as you go, then it works. This doesn't work for experts, but it works great for people with no prior knowledge.

So, you are confusing the concept with the delivery. The concept does not cause boredom, it's the delivery that does. And, I also don't mean you have to deliver it wearing a clown costume, I mean breaking it down in a way that builds the concepts from nothing.

So, I'm walking this edge right now with a few middle schoolers.

At the beginning of the (school) year, we started doing a programming class using scratch. The operative theory was to be able to explore, get the cause/effect thing going, some debugging, and be able to build something that they could distribute and have other people play. It was a success for a while, within a class or two, pretty much everyone had something that was more than just basic behavior. There was some animation, some 'cat chases mouse', and other basic games. But they quickly hit the wall where scratch is just painful to program. There's no abstraction, and if you want to do space invaders, you wind up copy and pasting a hell of a lot of code blocks. And woe to you if you then need to change something. Dragging and dropping is attractive till you need to build equations of motion.

So, beginning this semester, we're working through LPTHW. The class is smaller, some were definitely scared away by the "hard way" and my warning that they'd have to work. But the ones that are there are soaking it up. I think we're at ~ 5 lessons a week, based on one class time when they can do stuff + homework.

They're getting it. They can find bugs. They have seen where we can go (because of scratch) but they've also seen that there's got to be a better way than drag and drop. My goal is LPTHW should take a quarter, then we'll pull in pygame and some networking stuff, and do a basic networked game. My goal is to be able to translate one of their scratch games roughly block to line, then kick it up a notch. Seeing what I have, I should have abandoned scratch after a quarter, rather than a semester. It would have still given them the view of where we can go, but had them miss the more frustrating parts of the scratch environment.

I've now got some home school experience teaching kids from pre-k to middle school. Heavily scripted stuff is awesome, _provided_ the kids see where it's all going at the end. Far better than random or directed exploration. (I've seen this in learning to read, elementary math, programming, and an art class).

I can see how the standard "first class is scheme second class is discrete math" scares some away. How big of a population actually gets lured unto programmingblater in life?

I'm glad to be a piece of your evidence.

I have college degrees in Entrepreneurship and Marketing and have been just a "non-tech" guy for too long. I got tired of not being able to build anything myself, so I'm working my way through your book right now.

Of course I have a specific application in mind that I'd like to build, and perhaps this is evidence of my naivete, but it seems like if I were to just learn how to do that, I would be limiting my creativity. The difference between learning how to program only a specific type of application and learning to program in general seems like the difference between learning how to paint a bowl a fruit and studying the art of painting. What happens when you want to paint a bowl of fruit with a landscape behind it?

Again, I may just be one fool, but it is not the allure of being able to program a specific application that I am after, it is the pain of being ignorant that I am trying to assuage.

You present a false dichotomy. You don't have to choose to just learn how to program one kind of program or how to program generally. You can do both. And in my experience, having an idea and executing on it is a great way to start. You get instant gratification in learning one small subset of programming and you move on from there.

Reply on news.ycombinator.com