MSDN Magazine - March 2009 - (Page 31) TED NEWARD THE POLYGLOT PROGRAMMER Mixing And Matching Languages Long before the Web and client-server programming, it was common for an entire application to be written in a single language on top of a single platform or system. Consider, for example, the ubiquitous FoxPro platform, a staple of application programming for years. It provided a user interface format language and library, a data access and storage format, plus a collection of routines to provide the traditional library support, such as math and accounting. Both a language and a platform wrapped into a single environment, FoxPro was a classic example of how a programmer could learn one language/platform and remain successful and, more importantly, gainfully employed. Then came specialization—new languages and tools, each with a particular and specific purpose. Relational databases became the norm, and SQL became the language used to access them and modify them. GUI client development initially shifted to procedural languages like C and Pascal, then, with the advent of object-orientation came C++ and Delphi. Languages such as Perl and Python became powerful tools for administering a console-based operating system, most commonly UNIX-based systems, extending the capabilities found in command shells such as the Bash and Korn shells. Then came the Web, and with it HTML, CSS, and JavaScript became the languages of choice for user interface display. The programming language world has never seen a quiet moment, but in recent years, a large number of languages has exploded onto the programming scene, including procedural languages such as Ruby, Windows PowerShell and Python, and functional languages such as F# and Scala. Existing languages are getting new features, such as the data querying facilities Microsoft has added to C# with LINQ and now a new phase of programming language development has begun in which new custom languages, known as domain-specific languages (DSLs), are being developed for particular tasks or applications. For an example of a DSL, see the Service Station column from the Visual Studio Launch edition of MSDN Magazine (msdn.microsoft.com/magazine/cc164250). Everywhere you turn, new languages are popping up. While multilingual programmers certainly predate it, the term “polyglot programming” originated with Neal Ford’s December There are many languages out there, and there is likely one language especially suited to each problem you need to address. blog post (memeagora.blogspot.com/2006/12/polyglotprogramming.html), titled (not surprisingly) “Polyglot Programming.” Polyglot Programming OK, so we’ve established that there are a lot of languages out there, and there is likely one language especially suited to each problem you need to address. The savvy .NET developer needs to understand how they all fit together. That will be the focus of this column. Consider one of the most common problems today. Developers are being asked to scale their programs—their Web sites and services, in particular—to greater and greater numbers of users than ever before. Customers are being given access to their own account information directly. This means that where an application might have had to scale to a couple of hundred users (say, to increase the number of call center employee users during a growth spurt), now the same application must scale to potentially thousands, if not millions of users. Developers working on the Web site must manage to achieve both thread safety and good performance. Simply locking every method in order to serialize access through the entire system is not a good solution because it will not scale. Properly managing concurrency, especially as the application scales up, is no easy feat; it keeps even senior developers up late at night. Even with the release of new tools like PEX (research.microsoft.com/projects/pex) and CHESS (research.microsoft.com/projects/chess) to perform static code analysis and execute unit testing permutations to uncover multithreading bugs, you are still required to control concurrency yourself, and at a fairly low level, using either C# “lock” statements or the various concurrency-control classes from System.Threading. Are you up to the challenge? How good are your concurrency skills? Quick, what’s the difference between System.Threading. Monitor, System.Threading.Mutex, and System.Threading.Semaphore? Here you should begin to see the value of a particular language Send your questions and comments for Ted to polyglot@microsoft.com. March 2009 31 http://memeagora.blogspot.com/2006/12/polyglot-programming.html http://memeagora.blogspot.com/2006/12/polyglot-programming.html http://research.microsoft.com/projects/pex http://research.microsoft.com/projects/chess http://msdn.microsoft.com/magazine/cc164250
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.