Writing software is hard, particularly when schedules keep programmers “nose to the grindstone”; every so often, it's important to take a breather and look around the world and discover what we can find-ironically, what we find can often help us write software better.

Diversity in the workplace, declare the HR websites, is a good thing, crucial to innovation. Does this hold for programming languages?

While I was in college at the University of California, Davis, diversity was a hot topic among the students. In fact, one year, a half-dozen students decided that the Latino Studies department wasn't diverse enough (apparently, if memory serves, all three professors were of Caucasian descent), and staged a hunger strike “for diversity”.

I remember asking, as the hunger strike neared its second day, why diversity was a good thing. I also remember half the student body (it seemed) calling me an “insensitive racist chauvinist pig.” Despite all the words being hurled my way, I never actually heard an objective answer.

“Everybody knows” that diversity in the workforce is good. “Everybody knows” that diversity in a student body is good. What I can't figure out, however, is how it makes things good-what about a diverse workforce, exactly, leads to benefits not felt in a homogeneous one?

To the Internet!

Doing a quick Google search on “Diversity” leads to more of the same chest-beating “It just is” kinds of articles (and a couple of college message boards), but one article (http://www.businessnewsdaily.com/1200-workforce-diversity-good-for-business.html) actually offers up a rationale: diversity apparently, according to a Forbes study, leads to better innovation, which in turn leads to better competitiveness:

“Companies have realized that diversity and inclusion are no longer separate from other parts of the business,” said Stuart Feil, editorial director of Forbes Insights. "Organizations in the survey understand that different experiences and different perspectives build the foundation necessary to compete on a global scale."

Although no articles I've found make the causation clear, the correlation between a diverse workplace and innovation (and thus competitive strength) seems to be relatively clear, at least according the study cited. One of the key elements seems to be around attracting and retaining talented employees, which (to my mind) makes sense-programming is a pretty merit-based industry, when you think about it, given that neither the compilers nor the servers really care about the age, gender, ethnicity, political bias, or any other distinctive characteristics of the programmers involved.

(It should be pointed out, however, that programs sometimes bring their own biases to the game. For years, UNIX developers could feel a 60's vibe by trying to use their build tool; typing “make love” at the command line produced a result "not war?")

So if diversity at the racial and ethnic level is an important part of creating a competitive and innovative workforce, then why do programming shops continually stress that they are a monocultural place to work?

Why is “We are a C# shop, just a C# shop, and we will always be a C# shop (until Microsoft kills it, anyway)” somehow a good thing?

Polygamy, Polyamory, Polyglot-amy, oh my!

Most often, when I hear the argument against a polyglot environment, the arguments fall into one of the following:

  • Too many languages means we don't learn how to use any one of them well.
  • How will we ever find programmers who can write all these languages?

Generally, when presented with these arguments, I call their bluff: what if we substitute the word “languages” with the word “frameworks”? “Too many frameworks means we don't learn how to use any one of them well” certainly applies to a couple of shops I've been intimately involved with, sure. And “How will we ever find programmers who can write all these frameworks”? Sure. Find me the .NET developer who knows ASP.NET MVC, Entity Framework, WCF, Workflow, and the Base Class Library well. (Hell, for that matter, find me somebody who feels like they know just the BCL well, and I'll show you a programmer who hasn't really taken a hard look at how many thousands of classes and tens-of-thousands of methods are in it.)

Face it: programming is hard. The programming ecosystem is just far too rich and complex to expect to hire people who will know everything out of the gate. In fact, the polyglot project is already a fact of life. Consider the average Web project: How many different languages does the programmer need to know in order to be useful? A CLR language (C# or VB, usually), SQL, HTML, XML, JavaScript, CSS, a shell language (be that .bat files or PowerShell), we're up to a half-dozen already and we've only considered a Web app. Senior developers will often need to know a few more on top of that, just to be able to interoperate with other projects from other platforms or languages, to boot. Plus all those frameworks.

Of course, sometimes we just follow the herd:

  • C# programmers get paid more than Visual Basic developers, so it must be the best language to use, right?

That one wasn't even worth responding to. (I honestly heard that from a development team manager once.)

Sometimes, it takes the form of:

  • Eh, <language> is good enough for everything we do, why change?

Which is an argument I've heard over and over again from developers, which I always hear in my head as, “Dude, I just got to the point where I got enough C# (or VB) under my belt to be hired somewhere, don't go rocking the boat! Learning is hard!”

Then maybe you should go shopping, Barbie.

Thinking in Language

It makes me curious, though: again, going back to diversity arguments, what's so wrong with English? Why not just insist that everybody within the company learn English? I mean, English seems to work well enough for me, why shouldn't it work well enough for everybody?

(No, I'm not really arguing that. I happen to enjoy being semi-fluent in French and German.)

Monoglots of programming languages will be quick to point out that you can't have more than one language in your brain at a time - that taking the time and energy to master one will crowd out the others.

Does that hold true for spoken language? If not, then why the difference between spoken and programming language? If anything, programming languages are simpler than their spoken cousins (just ask any AI researcher). So it stands to reason that if I can't keep C# and ML in my head at the same time, I can't keep French and English there, either.

And yet, somehow people do this all the time. On the fly. During tense diplomatic negotiations. Far, far better than any computer ever could, for that matter.

So perhaps similar kinds of languages, like the C-family of languages (C++/Java/C#) are easy to hold simultaneously, but stretching across families (C-family vs Lisp-family or ML-family) is too far. Just like French (Latin-family) and Chinese (Far Eastern-family) are too… yeah. I guess somehow the Chinese and French have been able to talk to each other through interpreters, too.

And to the naysayers, I'll point out that sometimes, the point of learning other programming languages isn't to try and populate your place of employment with every language under the sun, but to stretch your mind in interesting new directions - and see that stretch rewarded with clarity when something new comes down the pipe.

Think for a moment about C#. In C# 2.0, Microsoft introduced anonymous delegates - blocks of code that could be trapped into a reference and passed around like objects. If you were one of those programmers who came from the C/C++ family of languages (probably passing through Java on the way), then you didn't see much point to this new language feature, except to make event-handling code a little easier to write.

But if you were a Lisp programmer, or a Ruby programmer, or a programmer of any other language that supports closures, you knew immediately what this feature was, and you knew immediately how it could be used to tremendous effect. Your designs could suddenly start taking advantage of this, and get significantly simpler and cleaner.

And when C# 3.0 started introducing more functional kinds of syntax and semantics, masquerading as LINQ, you again immediately recognized it as such and started writing code taking advantage of it. And when the Task Parallel Library and PLINQ came along, you just nodded knowingly during the session and started planning for how it would change your code.

Consider a simple concept like recursion: something that most programmers learn in an early programming lesson, by the time they reach the point of writing production code, they've learned the lesson that “recursion is slow, compared to iteration,” and put the idea on the shelf. What they never realize, then, is that recursion is slow in a language that has to create a new stack frame for each method/function/procedure call, and that in some languages, the compiler (or the runtime) can optimize the recursion into a single stack frame, regardless of how deep the recursion goes, using what's called tail recursion optimization. Or that some languages differentiate the passing of parameters by name, rather than by position (as C#, Java, C++, C, and so on do).

Or, if you knew Lua, or JavaScript, and their idea of “objects” (which are essentially name/value pairs), you realize that a Dictionary<string,object> that contains name/value bindings where the value could be those delegate instances sounds awfully familiar… and flexible…

And so on.

Just like knowing different spoken languages helps improve your understanding of your native tongue, knowing different programming languages helps improve your mental grip on the language used at home. It's not just a matter of an Eskimo having 27 different words for “snow” (which is a myth, by the way) and understanding that snow is somehow important to that culture - it's about seeing how different languages put concepts together and how sometimes that changes the perception of the concept entirely.

Wrap-up

For some people, these words will fall on deaf ears. Workplace diversity may be well and good, but clearly technical diversity is a Bad Thing�, and should be avoided at all costs. If Microsoft had wanted us to use dynamic languages, they would have built us one to use. If Microsoft had wanted us to use functional languages, they would have built it into the languages they gave us. And if Microsoft had wanted us to think outside of the box, they would have given us a new box to think within.

And to all those who argue this perspective, I have only one piece of advice, handed down to me from a man I worked for many years ago and deeply respect to this day: “Tell them that the phrase they will need to learn for their next job is �Would you like fries with that?'”

Or, if you prefer, “Voulez-vous mangez les frites”?