Along similar lines, one of the more interesting things I have observed is that the less experienced a practitioner of any given art, the more likely they are to look for the rare and unusual explanations *first*. One point I constantly impress upon my students is "Common things occur commonly" often more amusingly surmised as "When you hear hoofbeats think horses not zebras".

The common, run of the mill, and obvious answer is usually the correct one. It's always fun when you have to track down a zebra though.....

Thanks for an amusing meditation.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Says tachyon:

the less experienced a practitioner of any given art, the more likely they are to look for the rare and unusual explanations *first*.

That seems obvious. Why are inexperienced practitioners more likely to look for unusual explanations? Because they don't know yet what the usual explanations are, of course.

It seems to me that one of the most important forms of experience that people get is to learn which problems are common and which ones are rare. Sometimes beginners come to me with broken programs and ask what the problem is and I find it instantly. But when they ask me how they could have found the same problem themselves without asking for help, I don't have very good advice: I looked for that problem because I knew it was a common problem, and I knew it was a common problem because I had made the same mistake six times myself.

I agree with your observation that beginners often look in the wrong places. But I don't think that advising them to look in the right places is very helpful. If they knew what the right place was, they wouldn't be beginners.

--
Mark Dominus
Perl Paraphernalia

Of course what you say is correct that as you get more experienced you know where to look. Not only that you learn *how* to look. However even programming beginners should have learnt to look for say:

• typos
• missing semicolons
• mismatched quotes
• incorrectly paired curlies

as these are probably the 4 most common errors. Ever had someone with a simple typo suggest some bizare theorem for the disfunctionality of their code? That was not really the point. It was simply an idle refletion on life the universe and everything.....and I always like the thought of hoofbeats and zebras....

Perhaps the analogy is better with what I teach which is Emergency Medicine rather than coding.

compliments of the season to you

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Very nicely stated. And so far this has been an enlightening meditation. Now, to go a bit further to your thoughts I ask; Isn't the teacher suppose to be a "right place" to search for the answer when the answer isn't obvious? :)

_ _ _ _ _ _ _ _ _ _
- Jim
Insert clever comment here...

For the sake of a nice segue, I'm going to commit something that looks a bit like a dictionary flame. Since I hold dictionary flamers on a par with spammers (somewhere below pond scum.. a mental image I find pleasing), personal ethics demand that I first post a disclaimer, and give props where due.

So: bravo.. that was a nice, scholarly overview of Occam's Razor. It's rare to see someone actually go back to the source and discuss the idea thoroughly. The list of links alone earned you my ++.

Now I'll grab my hyper-pedantic asshole hat long enough to note that 'simplicity' and 'minimalism' aren't always the same.

William was talking about minimalism.. not using two pieces where one will do. The word 'simplicity' arrived later, which is nicely illustrated in the series of equivalent quotes you listed. All three of the earlier sources boil down to counting entities, as does Moody's from the present day. Only when we get to Einstein and Dirac does the more general concept of 'simplicty' come into play.

Sure, there's a version of simplicity that equals minimalism, but there's also a concept of 'piecewise simplicity' that almost inevitably leads to multiplication of entities. To quote H.L. Mencken:

For every complex problem, there is a solution that is simple, neat, and wrong.

That's something we, as programmers, need to care about.

I can't count the number of times I've seen code that starts from a few simple, easily-stated assumptions, then evolves into a Rube Goldberg machine due to inconsistencies among the assumptions. I've also spent a fair amount of time trying to pry coders loose from those simple-but-inconsistent assumptions so they can go back and write something that actually works. Some have defended themselves with the KISS principle, because digging out inconsistencies can be hard. More than once have I had to explain, "simple is not always easy," and, "simple means everywhere.. not just right here."

In the language of systems analysis, it's called 'globally suboptimal local optimization'.. fixing a problem in one place by creating an even worse problem somewhere else. If you really want to see that principle in action, divide a project among half a dozen coders, and reward them based on whose code profiles as fastest. It's a rare to find team that doesn't have at least one person willing to shove work off into somebody else's module.

So.. simplicity is a great goal, but remember to watch the global perspective. There are few better ways to write absolute crap than to get perky about making things 'simple' at the local level.