The Importance of Whimsy in Learning to Program | Hacker News Reader

The Importance of Whimsy in Learning to Program

natescottwest.com

This is something we've been thinking a lot about while working on the Khan Academy programming curriculum. We want the lessons and challenges to be fun, and to actually product something that the user can identify with (very often, an animal or food :-), but we also don't want to sacrifice teaching the concept in a clear way. For example, today we debated how to do our intro to loops tutorial, and we found that the clearest example wasn't nearly as fun as other possible ones - but it was the most clear, and for something like loops, we want to be really really clear when the student is first wrapping their head around it. We've written up some of our teaching thoughts here, but I'm sure we'll keep evolving them as we learn from our learners: http://cs-blog.khanacademy.org/2013/08/our-design-guidelines...

Thanks for sharing your experience!

Thanks for commenting. I would definitely say clarity comes before whimsy. That was part of my frustration back in college was the complete lack of clarity. Recursion was taught in about five minutes like this: "A recursive function is a function that calls itself until it reaches a terminating condition..." and then it was never explained again. No one got the recursion questions right on the end of unit quiz except the kids who had been programming since they were young. It wasn't until about 5 years later that I finally wrapped my head around recursion myself.

I really appreciate your comment. Education is really important to me and Kahn Academy has been a huge inspiration to me.

I understand and agree with your point, but not so much with your example. Recursion strikes me as a concept that is simple to explain (and the definition you gave is actually quite good) and hard to master, as in it really sets in when you practice it enough. I think the fault in how you were taught is not in the lack of clarity but that you should have been given a shitload of exercises on the topic.

Yeah fair enough. I wasn't really critiquing the explanation so much as that was the end of it. They also made us hand write assignments and quizzes thinking it would somehow keep us from cheating. It's been several years now so I wouldn't be able to accurately remember but I _feel_ like most of what we did with recursion from that point on was on paper and we were pretty much left to our own devices to figure out recursion...

Personally I can't stand "whimsical" tutorials to programming. Most of the time the author's attempts at humor just make me cringe. why's Ruby book is probably the worst offender. Couldn't make it past the first chapter.

Oh my, amen. That book actually made me question my decision to learn Ruby. I didn't want to identify with a community that was responsible for such an abomination. I ended up learning Lua instead.

This. And whimsical error pages, documentation, etc, are just showing the lack of writing skills behind. Google is full of those, and most of the time the allusion cannot be understood by those who are not sharing the same culture. That's utterly annoying. Did SICP writers feel the need to embellish their prose with eye winks?

Did SICP writers feel the need to embellish their prose with eye winks?

Yes? http://en.wikipedia.org/wiki/Structure_and_Interpretation_of...

Well, maybe my understanding of "whimsical" is wrong but it do not feel the same way to me. "Alyssa P. Hacker" is a poor pun that do not try to look clever.

I too found that a very frustrating book. I was struggling to understand two things rather than one.

Yeah, it's definitely not for everyone. It's just the kind of thing I would like though.

I find why's book really obnoxious, but I think learn you a haskell is excellent, so I don't really know if there's just a point where it's too much, or if sometime it's just done terribly.

Two such whimsical books are Learn You A Haskell For Great Good and Learn You Some Erlang For Great Good.

http://learnyouahaskell.com/

http://learnyousomeerlang.com/

For example, one of my favorite chapters in there is about distributed programming. It is told with an example of 2 camps of survivors of zombie apocalypse trying communicate with each other.

http://learnyousomeerlang.com/distribunomicon#alone-in-the-d...

You can tell Fred's (author) passion and enthusiasm from his style of writing.

I've worked through some of it! That's exactly the kind of stuff I'm talking about.

My Erlang learning has been a little spotty so far but I'm going to Erlang Camp in Nashville next month to fill in some holes. I've been playing a lot with Elixir and that's been helping too.

I'm on board with this, but my background in learning to code was a little different. My Java instructor (first formal programming class, but not first language) took the approach that teaching to code should imitate real things. So, our first few programs were around modeling real things in the world. We wrote a program to figure out why 7 was the most common number in gambling by rolling two virtual dice several thousand times and plotting the results. We explored the Birthday Paradox by randomly generating numbers between 1 and 365 until we hit a duplicate, and repeated that several times to prove the range. It was a great approach, and one that stuck with me.

That's awesome. If I had had a similar experience I probably would have been all in much earlier in my life.

use C++ to teach programming should be considered a crime. You simply don't give people who just got their driver license a truck to drive, not only will it suck out all the fun but also likely get the person killed in the process.

Oh, pish posh. Lots of people started with C++ and they're just fine. Sure, we had our share of segfaults and memory leaks, but it's better to learn what it is and how to prevent it early on rather than hide from it forever.

True, but starting from C makes more sense. C++ would be fine as a second language.

Actually, I agree with that.

It's not just a truck. It's a truck whose steering wheel is a chainsaw. And you are holding the chainsaw the wrong way.

Yeah, I think the short lesson here is that you really have to build something to learn to code, otherwise it's just not engaging. Not until you've built that first thing. Then it's like crack.

I've always been told this with mathematics. You won't really "get" it until you've done enough exercises, especially the more abstract you get (I'm looking at you, Category Theory proofs.) I don't know why it took me this long to apply the same principle to learning new programming languages. I always thought, well if I just start on this monolithic hobby project, I'll learn the language after having read xyz. Well, turns out, it's a lot more entertaining and faster for me to just blow through a bunch of medium-sized throw-away examples for a while first. That monolithic hobby project comes along much easier with less of a "I give up rate" afterwards, for me anyway..

Absolutely. I kinda wish I had written more in this post about context... I had a similar frustration with math even though we did many, many more exercises... Some kind of practical real world context really helps.

If you just naturally love math and think that way you can often see the context yourself anyway (or at least I did) but your average word problem at school isn't much of a real world context. When the hell will I sit around with my friends and say "Hey Jennifer, lets get that volume of beer in that cup. That sounds like a good time".

Spot-on. I never learned through the explanations in K&R; I just did the code examples and analyzed deeply stuff I didn't understand.

Really, most of programming is really easy. The boring stuff is reading library documentation and using libraries to do stuff.

This is where I meant to say YES! Absolutely! But I was on my phone and missed.

"...just think what naming an XML parser “Nikogiri” instead of “XML Parser” could do? Imagine if the C++ exercise above had just been FizzBang. That would have been tons more engaging." Tons more cringe-worthy, more like. We're not writing children's books here. The times I've enjoyed programming have been when I've worked with languages/libraries/tools that are intuitive/reliable/powerful and allow me to get shit done with minimum distraction by the irrelevant.

For instance, would python's "requests" library be more engaging if it was called ChittyChittyBangBang or YourMommaSoFat something else equally infantile? For me it would be less engaging. Names like this can also make people take a piece of software less seriously than they should, and harder to find because they are less descriptive.

I think that's a fair point. Guerrilla pretty much said what I would say... most of my production code just uses plain Jane clear names like "user" or a variable named "name_array".

The bigger message is to communicate that programming is fun to people who want to learn. I think you're average working programmer out there probably is... but my "educational" experience was not that way. It wasn't really about using whimsical names either, it was because it was taught so passionless and half-assed. I really am just saying this works for me and I see a lot of kids coming into Ruby and to Rails really getting a kick out of the small stuff... It's passion and it's details that are important... whimsy is optional.

* separate whimsy in learning from whimsy in the ecosystem: if the program is a teaching example in a book, then i think "Nikogiri" is an ok name, esp. if there are cartoons

* whimsy in the ecosystem is ok as long as it doesn't impede functionality. indeed, in some cases, a little added whimsy might help (human) memory in some hot spots: rfc3339-somethingorother is one example of a library that i'd like to have renamed "Nikogiri". there are like half-a-dozen of these little 100-line libraries for parsing date strings in python alone because everyone wrote one when the standard first appeared, all more-or-less with the same name, and even though a clear winner eventually emerged, its name still sounds like all the other packages'... and moreover i think this whimsy does exist in the wild. do you still <depend on google-collections? noo, we use guava now. did apt-get (yeah, the thing with "super-cow-powers") just decide i need libpdf-extra? noo, zathura depends on poppler. tools like pip and apt-cache provide a description field where greppable stuff like xml, pdf, and rfc3339 can appear for a reason: an xml library's name need not contain "xml".

* well-timed yo-momma-so-fat jokes will always be in style

I don't believe he's talking about what to name things in production code, but in tutorials. The author's on this thread though, so maybe he can answer. I just thought i should drop my 2c that reading a wacky tutorial (such as the one I just completed for Rust: http://www.rustforrubyists.com/) is much more engaging than reading Stroustrup's C++ book. In any production or even hobby code, of course, I would never name anything so strangely. I do think it's a great way to get started with all those throw-away projects it takes to become literate in the language.

There is a movement to "contextualize" introductory programming courses (and other CS courses) by teaching core concepts in the context of a problem domain that is meaningful for the students. Media computation is one such effort: http://coweb.cc.gatech.edu/mediaComp-teach

That ties in a bit with Seymour Papert's idea of teaching programming as a medium of expression. One part is having a meaningful domain, though an equally important second part is encouraging exploration and tinkering, rather than plowing through rote exercises.

Here's a passage from an old journal article I've long liked: http://www.kmjn.org/snippets/papert85_logovisions.html

That's lovely! Part of me thinks that kind of thing should have been more of the focus of my post.

Thanks for this. I've had a similar experience with learning how to program, having taken courses and doing examples which have had no clear purposes.

I'm 22 now and finally feel like I'm headed in the right direction with the help of BlueJ and a book called "Objects First with Java". It may not be 'whimsy', but I appreciate the fact that it helps me visualize the concepts of OOP.

I recognize the feeling of insatiability, as I keep wanting to learn more and more now, all thanks to brilliant resources.

Yeah... I may go through at some point and refactor this post some. I personally get a kick out of funny names and goofy stuffy but several people have made the point that it can be distracting to some people. The key things are just passion, clarity, and context. I experienced none of those things back in school... truly, not just from my programming classed but from 90% of all my classes. I can probably name all the good teachers I've had from grade school through university on one hand.

Great article - but please spellcheck. There are typos every other sentences, it makes the article quite painful to read- which is a shame because the content is interesting!

Thanks for the feed back... I really am a terrible spelling. I at least ran through a spell check and corrected those errors real quick. There's two errors where there's no space between a word where markdown is parsing it that way. Might just un-italicize those words later. If you notice any grammar mistakes that are annoying please feel free to email me and I'll fix them.

Lol. After reading my own comment I think I'm terrible at my native language, too. I need to stop writing things before I've had my morning coffee.

"typos every other sentence"

;-)

Yeah. It was painful to read but a good story. I think it's worth editing and cleaning up.

I find it absolutely frightening how much incompetent instruction there exists for teaching people skills like programming - with regards to the author's experiences, in particular. I'm glad that he finally found something that worked for him, but I'm left wondering how many other people will have had that caliber of instruction as their first (or only) exposure to the field.

Far far too many

The writing aspect of this is all over the place and really messy, but I liked his story and felt a strong degree of empathy with it—especially the part about false starts and bad computer science education.

Thanks for the feedback. I'm definitely not the best writer out there but would like to be... I REALLY should have ran this through a spell checker and felt stupid when I finally did. If you have any more detailed critiques and feel strongly enough about them to share please feel free to email me.

I would just like to thank dalanmiller for making a pull request to my fork of octopress correcting several grammar and spelling mistakes. That was a really cool thing to do and I appreciate it.

Yes! Absolutely!

Reply on news.ycombinator.com