And my books do exactly what this article says you shouldn't do.
I'd say if nobody wants to learn basic programming concepts from you, then it's not the concepts, it's you.
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.
But more importantly, I have evidence to back my beliefs. This article has absolutely no evidence.
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."
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.
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.
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 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.
As soon as I hit topics like OpenGL and networking, I realized this was going to be harder than I thought. The only reason I stuck with it is because I found joy in each little success, like sending a single character over a TCP connection, or putting a border around a <div>. And these successes continue to make the struggle worthwhile.
So this is totally anecdotal, but my personal experience conforms more with what Zed's saying. I think you won't enjoy programming unless you genuinely like the minute, seemingly boring details. Because those become your day-to-day consciousness far more than glamorous stuff like imagining new game mechanics and plotting out a storyline. (And that's assuming you're doing game development at all.)
Fundamentally, you're both teaching by example and the code is simple, so that the results have a clear correlation to it.
It seems to be an aesthetic choice as to whether you teach concepts outright and make it communicable with proper rhetoric or illustrate concepts by highlighting their use in a simple application. It's like two guitar instructors. One stresses etudes and practices alongside songs and another stresses songs alongside etudes and practices. I can't see either way hurting a student. Whatever the choice, you're packaging this information in a way that makes it digestible to those who want to learn how to program (either the way of rhetoric or application).
I would like to say this though, at least you guys are not teaching Java by programming within the Eclipse IDE, which isn't ment for beginners.
A few of us have even bought one of your books :-)
My mature students taking basic maths courses in the UK will read the textbook and come back at me with questions that show they have confronted the material and put some time into it. The teenagers need a different approach, games, Web sites with interactive material, carefully chosen written material.
Have you any age data about your participants? Perhaps the video courses?
Another thing to keep in mind is that a computer is already interactive. The idea that you need "graphics" to get students interested is completely unfounded, and the only data comes from experiments from companies trying to sell graphical programming systems for education sales. Even then these studies were done in the 70's and 80's when many people just didn't have computers.
In my experience I've found just making simple text adventure games is entertaining enough. Think about it: It's a game that is approachable by anyone, they are fun, they involve writing, their "graphics" are immediate, they don't require any geometry, and the output looks a lot like the program itself. That's why I teach them. They're easy but still fun.
My experience says you don't need crazy amounts of sensory input to keep people interested, and in fact is just distracts them and frustrates them. Keep it simple, but make sure it has depth that they can discover.
I remember in the early 90s plugging away writing various text games in QBASIC then excitedly showing them to school friends who's reaction was mostly "too much reading, not enough guns. Let's play Doom instead".
Of course this was somewhat disheartening and put me off programming for a few years.
The closest thing that I've seen to a comprehensive game creation "kit" is Unity3d but that has a pretty steep learning curve.
One sort of introduction that could potentially work well for teenagers would be to create a mod for an existing game that they already enjoy.
Also, what you describe is why I wrote:
Having said that I think you are right to encourage people to use code as a "secret weapon" rather than an end in itself. It is a great "awesomeness multiplier" to other skills.