Editor's Note

Overcoming Language Barriers with Elegant Design

Howard Dierking

Several weeks ago, I was in Barcelona where I was a speaker at the Tech•Ed Europe conference. To everyone who came to my session or stopped by the MSDN booth at the exhibition hall, many thanks—it was a fantastic experience that I hope to repeat.

On the last day of the conference, I decided to be somewhat adventurous, so I hopped on a subway and went into downtown Barcelona. I stopped into a small restaurant and attempted to order. I should emphasize the word "attempted" because nobody in the restaurant spoke English. And while I speak a whole bunch of Turing-complete languages, I don't speak Spanish. At any rate, the restaurant staff was very good-humored about my inability to effectively communicate what I wanted to eat (in fact, I imagine that my hostess is probably quite good at the game Charades). But that experience really got me thinking about the language tools we use—and how we use them.

As I'm writing this, Visual Studio 2008—and with it, C# 3.0 and Visual Basic 9.0—has been officially released to manufacturing and made available online to MSDN subscribers. As I'm sure you know, these new versions have even greater support for functional programming through core language features like lexical closures. Furthermore, the language extensions built in to support LINQ add a whole new level of expressiveness when it comes to a more declarative style of programming.

If you look around, particularly in Web development, you can see dynamic languages continuing to grow in popularity—so much so that Microsoft has built a runtime and set of language tools that allow popular dynamic languages like Ruby and Python to actually run on and take advantage of the Microsoft .NET Framework. And if you really want the best of all worlds (the safety of strong static typing with the feel of a dynamic language), you probably cheered Microsoft's recent announcement that F# would be released as an official, Visual Studio-supported language.

But it's not just about the choice of programming language anymore. Domain-specific languages are now starting to come into the mainstream, thanks in large part to the Ruby community. Even in more mainstream programming languages, debates around software design have shifted from object models and design patterns to the expressiveness of an API. As the complexity of software grows at an exponential rate, the requirements for programming languages grow in tandem. A language must provide more than just a means of generating instructions for the machine—it must allow the developer to express the actual intention behind code.

And it is with this notion of expressiveness where things get really interesting—because this is the characteristic that makes programming languages very personal. For example, let's say I want to find the number of words (we'll loosely define "word" to be a block of characters separated by a space) in this article with more than eight characters. Which of these is more expressive?

article.Split(new char[]{' '}).Where(w => w.Length > 8);

or

[\S\(\)]{9,}

The answer, of course, is that it depends not just on how you understand and think about the elements of software design but on how you understand and think about text parsing. Even within a single application, there are a variety of problems that, based on the individual, are most naturally expressed in different languages—and giving that individual the ability to solve those problems by using those natural expressions is the mark of elegant design.

Now, if we can just agree on a common language for ordering food ...

Thanks to the following Microsoft technical experts for their help with this issue: Cagri Aslan, Keith Boyd, Shawn Burke, Bill Chiles, James Clarke, Peter Donnelly, Charles Finkelstein, Elisa Flasko, Ted Hart, Pravin Indurkar, John Justice, Masahiko Kaneko, Lawrence Liu, John Robbins, and Chris Tavares.