rdn32

I’ve previously mentioned Rodney Brooks approach to robotics, and also “bottom up” views of knowledge. Here’s a nice quote (from Brian Rotman, Mathematics as Sign, p115):

Brooks’ attachment to the bottom-up procedure is also performative, ruling the description as well as the content of his approach. Thus, not only mind—problem solving, central control, representation—is subordinated within his model of intelligence but also its sociocultural correlates—philosophy, abstract thought, theory—are likewise invoked by him on a minimal, need-to-know basis.

This appeals to me, in part, because it chimes with my views about another form of abstract knowledge that’s central to programming: knowledge of programming languages.

When Sun Microsystems launched the Java programming language, it seemed to me that they were pitching it as being Visual Basic for Unix programmers (with Java Beans being the equivalent of OCX custom controls). Its purpose was to be a little bit like C++, but very much easier.

I could have made the effort to learn it then. I decided not to. This was partly for practical reasons (since getting Java for Linux was problematic at the time). The main reason, however, came from a rather arrogant assumption on my part: if I ever needed to know Java, then I could always learn it at that point.

Some years later I had a chance meeting in a pub with someone I used to work with. He’d co-founded a company. He was looking for programmers and, to cut a long story short, I ended up working for him.

The company was doing almost all of its development in Java, and I didn’t know Java. That wasn’t a problem: Java’s just a programming language, after all. After a week running through some tutorials I was good to go.

A number of the guys I worked with then are now in a different, newer company. (That’s the way things tend to work in this neck of the woods.) This company is doing its development in C++. The technical director described the shift to C++ as being “a bit of a baptism of fire” for one of my former colleagues. Whilst I can imagine that particular transition could be a bit rough, he’s a good guy, and ultimately it is just more stuff to learn. It’s not that big a deal.

At least, it shouldn’t be that big a deal.

The trouble with picking things up on a minimal, need-to-know basis is that it is hard to provide evidence that this can be done. Someone might say, for example, that there’s a big difference between having the basics and having enough depth of experience to do things in an idiomatic way. Hence, it does make sense—when hiring a programmer—to ask about the number of years experience that they have, or to ask language trivia questions.

Incidentally, I think this stuff about needing to know a language’s idioms is often nonsense. Obviously, it depends on the exact situation. But when to comes to getting up to speed with a particular code-base, or coming to a particular team, then understanding all the ways a language might be used can much less important that understanding the ways it’s actually used there.

So: what should be done?

Well, it’s not very practical either to assume that anyone can (potentially) do anything. On the other hand, only working with people you’ve worked with before would be rather restrictive.

Hmmm. I’m not sure that there is a solution to that one. It’s a bit of a puzzler.