A Framework for New Languages
In the past couple of years, an interesting trend—starting with the Java Virtual Machine's original release—has begun to take root in the .NET world as well: Some researchers started building their languages to run on top of the CLR. They do this not just to make their languages and tools available for .NET developers to use (although that's a nice side benefit), but because when they target the CLR, a large number of problems they don't want to solve (creating a garbage collector, a module-loading facility, access to the underlying platform, and so on) is already solved for them. They simply build their language to emit IL instead of native code, and suddenly, they can take advantage of everything the CLR offers, from ADO.NET to WPF to Castle to NHibernate to…you name it.
All this leaves academics and researchers in a better place, but so far it still ignores the line-of-business developer. This article started with a developer looking for a way to build high-scale concurrent applications. So far, I've established that while academics and researchers improve the development world, delivering their benefits back to the "mainstream" development community is a slow process. It takes a while for new concepts and ideas to filter their way from research to mainstream. After all, it took object-orientation something like 25 years to move from the academic/research world into the mainstream programming world.
|Author's Note: Somewhere in the back of the room, a hand is waving madly and its owner is shouting "Smalltalk! Smalltalk!" Sorry, dude. Yes, Smalltalk was useful, yes it was powerful, but you'll have a hard time convincing me it was ever "mainstream."|
Fortunately, the new programming language renaissance is being created on top of the platforms already available in commercial enterprise settings—the JVM and the CLR. So when an academic decides to move the OCaml programming language to the CLR, line-of-business developers can use the work almost immediately.
For example, one Microsoft Research project called "AbsIL" made it easier for developers to take compiled assemblies, untwist them back into a tree structure (called an Abstract Syntax Tree) and modify the code before re-emitting it as compiled assemblies. This is intrinsically a functional type of operation; given the same input, the code will always generate the exact same output. Consequently, as the Microsoft researcher responsible for AbsIL built that library, he also sat down to produce a CLR version of OCaml.
But to make OCaml-on-CLR work correctly, he first had to implement a form of parametric polymorphism for the CLR, which he created as a series of source patches on top of the Microsoft open-source .NET implementation, now known as the Shared Source CLI, or "Rotor." That set of source patches is still available to this day, named "Gyro."
Still not convinced that all of this has relevance to the line-of-business developer? You might change your mind when you realize that the series of source patches to "Rotor" became the seed for the generics model that Microsoft folded into the CLR in the .NET 2.0 release, and that the CLR-based version of the OCaml language came to be known as "F#," which will be included in Visual Studio 2010.
In fact, the next generation of the .NET platform is about to explode with new languages. In addition to F#, Microsoft will release two more languages via the open-source community: ports of Python (IronPython) and Ruby (IronRuby). The rest of the community is also stepping up to the languages plate, with new languages such as Boo, Nemerle, and P# (Prolog#) that add even more variety to the mix.
Get In Front of the Wave
Moreover, this increased focus on creating languages makes it easier for developers to build their own languages—whether a "DSL" or something that makes it easier for other line-of-business developers to focus on their chosen tasks. Using some good examples already available, such as Joel Pobar's "Good For Nothing" compiler from TechEd a few years ago, a developer can produce a first simple custom language in about a day—even with no prior experience in building languages.
This isn't to suggest that every single project anyone works on from here on out is going to require a custom development language or a DSL; like all new tools, there is a time and a place for building a custom language or a DSL. But it is fair to say that the next five or ten years is going to see an explosion of new language interest and implementation, and ‘tis the wise developer indeed who looks to get in front of the wave to ride it, instead of paddling like mad from the back.