Code Is Not Literature 240
An anonymous reader writes "Hacker and author Peter Seibel has done a lot of work to adopt one of the most widely-accepted practices toward becoming a better programmer: reading high quality code. He's set up code-reading groups and interviewed other programmers to see what code they read. But he's come to learn that the overwhelming majority of programmers don't practice what they preach. Why? He says, 'We don't read code, we decode it. We examine it. A piece of code is not literature; it is a specimen.' He relates an anecdote from Donald Knuth about figuring out a Fortran compiler, and indeed, it reads more like a 'scientific investigation' than the process we refer to as 'reading.' Seibel is now changing his code-reading group to account for this: 'So instead of trying to pick out a piece of code and reading it and then discussing it like a bunch of Comp Lit. grad students, I think a better model is for one of us to play the role of a 19th century naturalist returning from a trip to some exotic island to present to the local scientific society a discussion of the crazy beetles they found.'"
Re:Similar language, describing different things (Score:2, Informative)
How about sorting a deck of cards using two of the algorithms you mentioned, quicksort and mergesort.
Quicksort: Take a deck of cards, and pick a random card. Form two new decks by placing all cards smaller than it to the left deck and the larger or equal ones to the right deck. Repeat this for both decks, so you get more decks. Never move a deck over another. At the end just combine the decks from left to right in increasing order.
Mergesort: 1. Place all cards on the table, each on its own slot. If there's not enough space, form decks of five cards each and sort them manually. 2. Take the two piles with the least cards in them (or close enough, doesn't matter). Find the smallest card in the two piles, and put it on the table. Put the next smallest table on top of the previous one, and so on, until there are no cards left. Leave the resulting pile on the table and continue from 2.
Of course, a non-organized person might mess the decks, but others should be able to understand these. These instructions should give the correct asymptotic running times, assuming for example that the person realizes finding the minimum is quite simple when the decks are sorted.
Re:Similar language, describing different things (Score:5, Informative)
but for the majority of the population something like mergesort, quicksort, or heapsort is going to seem like voodoo no matter how elegantly it is coded.
Explaining quicksort to the layman.
Here's a 1000 names on little cards. Pick one at random and look at the name.
Sort the names into three piles - those that come earlier in the list, those that are the same as the name, and those that come later than the randomly selected name name.
Put the "earlier" pile to the left of the "same" pile, and then put the "later" pile to the right of these two.
Great? Done that?
Now repeat on the process on each "earlier" and "later" piles, Do this over and over again, giving you smaller and smaller piles. It doesn't really matter which pile you split first, just as long as you don't mix up the relative left/right ordering.
Eventually you will end up with lots of small piles of cards that contain all the entries of the same name.
And then, as if by Voodoo., all your names are now in order from left to right.
This can be parallelised - if you want, you can out-source some of the work to friends and family, to speed things up.
Re:Similar language, describing different things (Score:5, Informative)
And yet, once again, I used to teach quicksort to 4th graders- when I was only an 8th grader myself. While it is possible that the general population has gotten significantly less intelligent in the intervening 30 years, it isn't very likely.
If you can't comment in plain english, then your code is not maintainable.
Re:Music... (Score:5, Informative)