Monday, June 25, 2007

Deep or Wide

Put on your hip boots, it's about to get deep here.

The other day I was thinking about how hard it is to be a Java programmer when I realized something. Old style languages like Pascal were very small so that in order to do anything useful, you had to know a lot of good algorithms. On the other hand, a modern language like Java is very large and already has support for most common programming tasks. This calls to mind the depth vs. breadth tree search problem. Under this metaphor, being a good Pascal programmer involves a lot of depth, but not a lot of breadth of knowledge. Whereas being a good Java programmer involves having a large breadth of knowledge about the libraries, but very little depth about how they work.

These are fundamentally different kinds of knowledge, and different programmers will attain proficiency at each language differently. Java, or indeed any modern language, requires memorization of vast numbers of APIs. Otherwise you risk reinventing the wheel, and the bugs that go with it. Which methodology is superior? I suppose I must reluctantly admit that breadth overcomes depth more often.

The depth vs. breadth tree search is often explained in the context of game theory, especially using chess as an example. As a chess player I have always relied on depth as a strategy, but a good player with a broad knowledge of standard chess openings will beat a depth first thinker every time. This is unfortunate, since it means that to be a serious chess player implies years of study and memorization just to know the state of the art. No one enjoys this, but it is necessary to be taken seriously.

What is true for chess players is also true for modern programmers. Is there any escape from the problem of rote memorization? All professional fields have this problem, but programmers are different. We don't have to live within the limitation of human brains. Isn't there a software solution that will free us from the chains of memorization? I know it isn't Google. That instrument is way too blunt. It isn't Javadoc. That is too tightly focused. It is something like Googling Javadoc though, with more intelligence. I want something that reads my code, determines basic purpose, and suggests possible solution classes that are appropriate to the job at hand. A kind of automated design pattern filter. Not AI, mind you, just good old fashioned breadth first tree searching.


No comments: