I’ve spent my life immersed in language. By the time I graduated from high school, I’d studied at least a dozen: French, Spanish, Italian, Esperanto, Russian, Mandarin, Irish Gaelic, German, Latin… French is the only one I learned very well, but still I developed a profound appreciation for how study of one language can enrich my understanding of others, including and especially my native tongue, English. In college, as a French major with a linguistics emphasis, I of course studied even more languages. Frequently I found myself better able to express or understand certain ideas in languages other than English.

My father was a programmer and often expressed his conviction that there is a connection between languages used for programming and those for human communication, asserting that they occupy the same area of the brain. I have no idea whether that’s true, but it sounds reasonable and I’d believe it. He, too, had occasion to learn new languages for his work, although the only ones I ever knew about were C, C++, Ada, and possibly COBOL. I think it no accident that the first programming language in which I felt truly at home was Perl, which is strongly influenced by linguistics and ideas about human language and expressiveness (see, for example, Allison Randal’s “On Topic“).

It should come as no surprise that now, as a working programmer, I believe the study of multiple programming languages to be not only extremely valuable, but essential. And maybe it’s close-minded of me, but it surprises and disappoints me when other programmers do not feel the same. I work on a team of Java programmers, and with one exception I am the only one who is even remotely interested in things outside the Java world. This is crippling. That sounds like an exaggeration, but I believe it to be true. A monoculture is limiting and dangerous. It doesn’t matter whether you’re working with .NET, Java, Ruby, or whatever. Working under the assumption that a single tool can be an effective one-size-fits-all tool is a serious mistake. It limits your thinking, it limits your creativity, it limits your ability to solve problems.

Here’s some advice I recently gave someone who was looking to hire a .NET web developer:

I’m not suggesting that you hire someone who isn’t strong in .NET. If you don’t currently have strong .NET skills, then obviously that’s a very important consideration. Neither am I suggesting that you look only at developers with experience in .NET and something else. I’m suggesting that a candidate who has experience with .NET and another platform may — may — turn out to be a stronger candidate because s/he can critically assess what .NET has to offer rather than blindly follow the One True Microsoft Way.

I work with Java programmers. That’s what they are: Java programmers who happen to be working on web apps. Except for maybe something like Scheme covered in an intro computer science course, they don’t have experience with anything but Java. And it hurts us. Because when they look at a problem, all they see is Java. When I suggest a way of doing things that isn’t a canonical approach in the Java world, I get strange, uncomprehending looks. And we end up with overarchitected, overcomplicated application designs that solve problems we don’t have — or that fail to solve the ones we do have.

Example. An complicated call stack for a form submission that retrieves search results. POST form, push criteria to the call stack, redirect to a GET to the results display page, pull criteria off the stack. Okay, the call stack isn’t complicated, but the code behind it was. The programmer who designed this spent a long time working this out and unsuccessfully trying to address problems like dealing with multiple windows. Solution? Submit the form with GET in the first place. Dead obvious to a web developer, not so much to a Java programmer who’s not used to the web. But maybe that’s not fair since it’s a domain problem.

Example. A former coworker insisted that the text output of a certain COBOL program could never be parsed and made into something more meaningful. Why? Because he was exclusively a Java programmer, and Java’s a pain in the ass for text manipulation. Well, I work with languages like Perl and Ruby, steeped in a history of text manipulation. I munge text for breakfast. I looked at the problem and figured it would take about half an hour with a few regular expressions. Java didn’t even have regular expressions in the core API until four years ago, so this way of approaching a problem still doesn’t occur to most Java programmers.

Example. I find myself cleaning up a lot of clunky JavaScript code, written by people who treat it as “Java Lite” and who don’t understand JavaScript’s object model, which is quite different from Java’s. Different, not worse — and certainly not the One True Java Way.

I’m not writing this to rag on Java programmers, it’s just that they happen to be the source of my daily frustrations.

All this said, it’s quite possible to have an excellent web developer who knows only Java, or .NET, or ColdFusion, or PHP, or whatever. Regardless of whether they’ve worked in a diversity of languages or have been steeped in a monoculture, I think it’s worth asking about the strengths and weaknesses are of their chosen platform, because it’s a strong indication of how carefully and how creatively they’re thinking about the problems before them.

This is part of why I worry about what to suggest instead of Java EE, or rather what we can introduce to Java EE to be more productive. Part of my growth as a developer has been learning that not everyone has an easy time learning another language. I have always had an easy time learning languages, whatever the sort. I love to learn a new language, to stretch my mind and see what it has to teach me. This is far from universal. But I have to keep reminding myself of that, especially when I have trouble understanding why so few people are interested in extending the Java platform with non-Java languages.

More on that another day.