Slashdot Mirror
Learning To Code: Are We Having Fun Yet?
theodp writes "Nate West has a nice essay on the importance of whimsy in learning to program. "It wasn't until I was writing Ruby that I found learning to program to be fun," recalls West. "What's funny is it really doesn't take much effort to be more enjoyable than the C++ examples from earlier...just getting to write gets.chomp and puts over cout > made all the difference. Ruby examples kept me engaged just long enough that I could find Why's Poignant Guide to Ruby." So, does the future of introductory computer programming books and MOOCs lie in professional, business-like presentations, or does a less-polished production with some genuine goofy enthusiasm help the programming medicine go down?"
The important thing about learning to code is keeping interest/motivation to do so.
I agree with the general approach that the essay espouses - whimsy is a great way to keep interest; but it's certainly not the only way. Different things work for different people. My daughter is two and a half years old, and so far has totally rejected learning that involves traditional 'reward' such as the way gCompris shows 'happy' images on completing tasks vs 'sad' images when failing. However, what seems to do it for her is being able to 'show off'. When she can make her grandmother surprised by being able to point out letters of the alphabet on things, she is much more motivated to learn and get it right.
I'm sure my daughter's learning style will develop and change as she grows; I just wanted to use an example that demonstrates not everyone is motivated to learn in the same way. I don't think coding is any different.
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan
PHP is a much, much better choice! Everything just fucking works, even when some parameters are wrong and you're mixing variable types all over the place. /duck
Get free satoshi (Bitcoin) and Dogecoins
The author has a point, maybe. I did notice that he was ten years old in the nineties and learned to program after college, meaning he has maybe five years of experience. He may be missing the REASON you name it "XMLReader", not "SusieQ" or whatever he said. If he ever has to grok a medium sized project full of classes with "whimsical" names he may wish for clear, intuitive names.
My predecessor at work was whimsical - every script or class has a variable named "bob", which sometimes is important, sometimes does nothing. Occasionally, he forgot what he was using bob for in a particular function and tried to have it represent two different things. One of our tasks is to slowly replace all of his whimsical code with proper code that is reliable and self documenting
My understanding is that management only hires people who have fun doing their job because management is largely made up of Funpires who need to slowly leech the fun out of their victims, leaving them soulless corpses.
Seriously, why else would they veto Pants-Free Fridays?
When I was an undergrad with a part time job helping out in a graduate chemistry lab, there was a suite of utilities written in FORTRAN. People depended heavily on this suite to calculate all manner of things related to their crystallography research.
The problem was, it was mostly written during one of those years where Lord of the Rings and the Hobbit were massively popular again, and people were learning to program with hunt-the-wumpus teletype programs. The original author "amused" himself by naming pretty much anything he could after some fantasy concept. CASTLE, FRODO, DRAGON, and so on. Okay, so to map out van der Waals surface strength, you ran CASTLE. Many things have quirky codenames, you get used to it. But all the variables followed suit. Now it was a bit more obscure to maintain the program or trace the logic.
Worst of all, the comments. In FORTRAN, columns 1 to 72 were for your program, and anything after 73 was a comment. The author wrote an "epic" of his own, all word-wrapped in the column space from 73 to 132 (the width of common teletype paper and long Hollerith punch cards). What a waste of his time, you might think. But it was also a huge impediment to maintenance; you see, people in the lab LIKED his story (for a while), so they had to figure out how to patch the logic without breaking the flow of the story. It took years before someone stripped all the prose and got the rest of the lab to follow the maintainable fork instead o the prosaic one.
[
Even if you don't wind up doing a better job, reinventing the wheel is a good way to understand how wheels work. So the effort isn't wasted if one learns something at the end of it.
Ita erat quando hic adveni.
I had much the same reaction to perl. I love perl for many reasons. One is that even though the native language without any imports is more powerful than almost any other languange (without imports) the O'reily nut shell guide is the thinest one on my shelf. It really says something about incomprehensibility when even the C++ nutshell guide is thicker than perl. It means that even though perl might seem very ad hoc, in fact it's so self consistent that you can write it all up in a tiny guide.
What really sold me on perl was writing object oriented perl. I had been doing object oriented programming for some time in multiple languages including java and Objective C, but what really made me understand it was perl. In perl you actually see the underside magic of what an object actually is. It's remarkable that the language of perl could go from not having any objects to having objects just by adding one additional command ("bless"). Nothing else in the language had to be re-written. Internally one is storing all the instance variables in a single hash. What's interesting is that you don't have to choose that mode of data organization. you can instead bless a scalar. then you can have the class rather than the instance manage the instance variables. Effectively a hash is a row oriented data base and a scalar is a column oriented data base. When I realized this I was sort of staggered how many high concept ideas were rolled up into the perl method of objects.
I went back and implemented a hash in fortran 77. After that I could write Object oriented fortran 77. yep that's right fortran can also be an object oriented language just doing the same trick perl does. All you then are missing is dynamic memory allocation for it to be complete.
While may people curse perls prefix sigils I actually find them conceptually compact. In most languages the notion of a type, and the construction of a primitives data, get conflated. Really these are different things. Perl makes this explicit. A primitive in perl can have a data organization (list, hash, scalar, reference, dereference, glob) signified by a pand it can separately have a package inheritance (@ISA) that is analogous to a type. In languages like C++ or most everything those two concepts are not distinguised heavily. As a result I find it easier to read a perl program because of all the explicit data structure prefixes.
What kills perl in the end for complex programs is not these sigils looking like cursing on the page, but rather that everyones programming style is different, so it gets pretty crazy to read because it's so compact. It's perhaps a compliment how compact it is. It's interesting that the less compact and less versatile a languages native syntax is the easier it is to read.
But it's true. Try reading APL, the most dense language ever devised. then try reading Lua or (early) python. Both of those are a breeze to read other people's code.
When I read ruby what I see mainly is an extended perl syntax that can avoid using these despised prefix sigils. It gives the objects syntacic sugar, like python does, to hide the object mechanics from you. So it's a very clean looking upgrade to perl.
Some drink at the fountain of knowledge. Others just gargle.