Learning Programming

Do read Peter Norvig’s Teach Yourself Programming in Ten Years. Here’s an excerpt:

Researchers (Hayes, Bloom) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. Samuel Johnson thought it took longer than ten years: “Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price.”

Dynamic Typing and XP

What’s up with dynamic typing and XP anyway? It seems like here are hordes of lemmings out there repeating one after another: “we don’t need static typing; we have unit tests.”

Yeah right.

Caspers Jones has reported some 15 years ago that no single quality assurance practice catches a significant percentage of defects. Unit tests, in particular, catch between 10 and 50 percent of defects, with 25 percent being the modal value.

25 percent. Say that again: 25 percent. That’s how many defects you can catch with unit tests in the average case.

Is this surprising? Not really. Unit tests fail to catch a great number of defects. Threading problems, problems with streaming data, resource leaks, etc. Wonderfully enough, some of these problems can be detected by strong typing.

And in our business, the line that separates professionals from amateurs is their treatment of defects. Professionals are aware of the risks that defects represent and cast as many nets as feasible in order to catch them. Amateurs do one or two things that they have read about in the latest issue of Dr. Dobbs and hope for the best.

Locking Any object

In Java it is possible to synchronize on any object:

synchronized (anyObject) {
    ...
}

This is stupid for two reasons. It increases the chance that you’ll synchronize on the wrong object somewhere in the code, and it increases compiler complexity. Was it that hard to limit synchronization to a specific class made for that purpose?

I had hoped that people at Microsoft knew better. But bad ideas don’t die. They get copied.

How does one enter a critical section in C#? Using any object, of course:

lock (anyObject) {
    ...
}

Stupid. Stupid. Stupid.

The Joy of Static Typing

Never send a human to do a machine’s job. — Agent Smith, The Matrix.

Back when I was doing most of my coding in Java I screwed up a couple of times and tried to wait() or notify() a semaphore that I didn’t own.

Yesterday I was using C++ and .NET. I created a class named Lock that obtains a lock in its constructor and frees the lock in the destructor. The usage is similar to the synchronize blocks used in Java and C++:

{
    Lock lock (mySyncObject);

    ...
}

Then I remember all the problems I had with Java. So instead of having Wait and Pulse (CLR version of the Java notify function) operate on mySyncObject, I had them work on the Lock object:

{
    Lock lock (mySyncObject);
    lock.wait ();

    ...
}

This eliminates the whole class of bugs where wait() and notify() are called without the ownership of the semaphore.

Boy I love static typing!

Geek Humor

I found the following text while browsing Phil Wadler’s website:

Said the frustrated formalist, “Hype
Often comes with no clear static type,
But as long as it parses,
Those pragmatic arses
All say I have no grounds to gripe!”
    — Jonathan Robie

ANSI-Compliant Visual C++

Chris Sells writes that Microsoft has demoed a ANSI-compliant internal build of VC++. Read Chris’ report here.