Tuesday, May 15, 2007

The Importance of Language

Language is important.

One of the purposes of my last two blog posts was to use hyperbole to make a point. And, judging from the hue and cry, I was successful in irritating a lot of people. To do that, I used 2 purposefully inflammatory terms: "communist" and "bureaucracy". As many people pointed out, communism as a form of government is clearly a bad thing, as proven in very expensive social experiments in the last century. Bureaucracy, though, merely has a negative connotation because it tends to be misused. In very large groups of people, some level of bureaucracy is necessary to preserve order. It is in the arbitrary application of bureaucracy that earns it a negative connotation.

When you read the first sentence of this post, you probably though I was referring to computer languages, not English. That's a perfect example of how spoken languages are sometimes ambiguous in useful ways. In fact, poetry is an art form that takes good advantage of the imprecise nature of our spoken languages. It is in fact hard to create a useful human language with very strict, unambiguous rules (as Esperanto showed). I'm sure lawyers would love to have a language where nothing is ambiguous; it seems like a large part of contract negotiations concerns removing ambiguities and trying to craft real, objective meaning from our incredibly malleable language.

Computer languages are important in just the same way as spoken languages. When creating a bureaucratic, legalistic system, strong contracts and unambiguous language matters. Very large systems benefit from bureaucracy. Using Java, C#, or some other statically typed language for building incredibly large applications takes advantage of the useful bureaucracy inherent in the language. I used to think that this serious hampered the ability to build large, complex systems in dynamically typed languages. You necessarily remove some of the useful ambiguity from such systems.

Some of the richness of spoken language hinges on purposeful vagueness. This means that syntax matters (in both spoken and computer languages). Ultimately, computer languages help us operate Turing machines, which means that any Turing-complete language will allow you to do anything you want, contingent on effort. As Paul Graham aptly states, you could build all of the features of Lisp using C, but the shortest route would be to build a Lisp interpreter in C, then write your Lisp code on top of that.

That suggests that the choice of language depends on the useful tension between inherent capabilities, expressiveness, rules, and the productivity because of the interplay between these factors. This helps explain why there are thousands of computer languages, each finding their own combination of those factors. Paul Graham has a great essay about languages, power, and suitability called Revenge of the Nerds.

Computer languages are just tools, and I try not to get religious about tools (my inflammatory posts for effect to the contrary). I personally have changed my views over the last few years about the efficacy of dynamically typed languages like Ruby, even for large enterprisey applications, as long as you have strong testing to back you up. The flexibility of the meta-programming in Ruby allows you to solve hard problems in elegant ways that are either too cumbersome or just flat impossible in a more limited language (even if those limitations are on purpose). Rails is a great example of a framework builder pushing the really powerful features of the language and in the process creating a framework that you don't need to know all those things to operate. Limiting the power of the language hurts your best programmers the most. The interesting question is: given the productivity difference between the best and worst developers, how much to you want to limit your best developers at the expense of "protecting" the weaker ones? And, before you think that bureaucratic languages make bad developers safe, consider the great quote by Glenn Vanderburg (based on his experiences in the real world) : "Bad developers will move heaven and earth to do the wrong thing."


Todd said...

How exactly did Esperanto show that it's hard to create a useful language with unambiguous rules? Do you mean unambiguous *words*? If so, that wasn't a design goal of Esperanto, so I don't see how Esperanto illustrates it more than any other language.

Neal Ford said...

No, my meaning was around the unambitious grammar and word construction rules (based on the Wikipedia entry on Esperanto -- it's on Wikipedia, so it must be true!). From my understanding, one of the goals (which is laudable) is to solve some of the ridiculous rules of a language like English.