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