Polyglot Programming: Building Solutions by Composing Languages Polyglot programming refers to leveraging existing platforms by solving problems via solutions that compose special purpose languages.This concept leverages the multi-language nature of the CLR to create simpler solutions to vexing problems. This article delves into the motivation, benefits, and challenges of writing applications in this style. Back in 2006, I coined the term polyglot programming in a blog post. It is not a new concept (being at least as old as Unix and probably much older-I just attached a modern term to it). That blog post was a response to what some are calling a renaissance in computer languages. Polyglot programming refers to using special purpose languages combined in the same context to create better problem solutions. To fully appreciate this concept, I’m going to review some recent history about the abstraction mechanisms that developers use to solve problems today, and point to a new way to do so in the future. A Historical Framework For the last 20 years or so, developers have been building virtually all applications using object-based languages. One of the promises of object orientation is ease of code reuse. Certainly, the core characteristics of object-oriented languages provide the facilities for reuse: encapsulation, polymorphism, and effective abstraction. But developers found it hard to achieve large-scale reuse using these atomic building blocks. So, they’ve resorted to two approaches that use object-oriented features as building blocks: components and frameworks. Components work extraordinarily well for visual reuse. First VBX, then ActiveX controls showed that you can create a vibrant ecosystem of reusable components. Building non-visual behavior is harder. Windows platform developers have made attempts with lots of corresponding acronyms: COM, COM+, MTS, BizTalk, etc. And that’s just the .NET space. The Java world took the good ideas of MTS and went down a long, dark path with Enterprise Java Beans. And yet none of these techniques for achieving business domain reuse has worked well (which is why we keep trying). Components rely on a certain physical ecology to work: tools that understand how to display property inspectors, event mechanisms, and lifecycle control for the components. This ecosystem represents the other great example of code reuse: frameworks. Frameworks have become the preferred reuse mechanism. Frameworks consist of a large number of related classes with shared context. The most pervasive is, of course, the .NET Framework, and it includes several smaller frameworks (ADO.NET, ASP.NET, etc). Ancillary frameworks exist outside the Microsoft-supplied ones: log4net, nHibernate, iBatis.net, nVelocity, etc. None of this is news, of course: as a .NET developer, you’ve been steeping in this abstraction style so long you no longer even notice it. But underlying this abstraction mechanism is the idea that you can have one true language to solve every problem. The one true language in .NET is either C# or Visual Basic. These general purpose languages allow you to interact with your component and framework reuse mechanisms. This works well for many of the kinds of applications you need to write, but it has its shortcomings as well. The idea that you can create a single computer language that solves all (or even most) problems ignores the vast variety of problems that developers must solve. Extending the one true language with frameworks helps with difficult abstractions, but mask the fact that sometimes the language you use is poorly suited to the problem you are trying to solve. Object-orientation is an effective abstraction mechanism for much of the world because it organizes things in hierarchical fashion. Most of the world (as viewed by developers anyway) is hierarchical or can be mashed in to a hierarchy. But developers keep running into cross-cutting concerns: transactions, logging, security, etc. These don’t fit well within our existing hierarchies. This idea is illustrated in Figure 1. Thus, aspect-oriented development was born. 
Figure 1: We need cross-cutting concerns to handle some of the problems that routinely arise.For those not familiar with it, aspects weave code into existing hierarchies. Aspects have a specific syntax (different from either C# or VB) that describes pointcuts, or places where you can inject code (using a special compiler) directly into the compiled artifacts. Aspects allow you to define logging code in one place, and the aspect compiler injects byte code into your compiled code to add the necessary code to make all your logging calls. Consider this simple class: public class MyClass {
public int ProcessString(String s,
out string outStr) {
// ...
}
}
If you want to add a logging call determining when this method executes and when it stops executing, you’d have to hand-write it like this: public class MyClass {
public int ProcessString(String s,
out string outStr) {
log.debug("entering ProcessString
method");
// ...
log.debug("exiting ProcessString
method");
}
}
Instead, you can add an aspect that allows you to intercept particular method calls for a class. using DotNetGuru.AspectDNG.MetaAspects;
using DotNetGuru.AspectDNG.Joinpoints;
public class AspectsSample{
[AroundCall("*
MyClass::ProcessString(*)")]
public static object
Interceptor(JoinPoint jp) {
log.debug("entering ProcessString");
object result = jp.Proceed();
log.debug("exiting ProcessString");
return result;
}
}
Both the class name and method name can use wildcards like the namespace in the example above to allow this to work on a wide variety of classes. This example uses the AspectDNG AOP compiler for .NET, one of several open-source options. This is more convenient than writing all that logging code by hand in every place it’s needed. But it also shows that the abstractions offered by the underlying language (C# or VB) are not suited to solving every problem. And that’s fine. We’ll probably never create a language that’s suitable for every situation. In fact, we should stop trying. Microsoft designed the CLR to host multiple languages with a common target intermediate representation (IL). Why not leverage that more aggressively than we have in the past to create solutions by composing languages within the same solution? | & | | 
By: Neal Ford
Neal Ford is Software Architect and Meme Wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. He is also the designer and developer of applications, instructional materials, magazine articles, courseware, video/DVD presentations, and author and/or editor of five books spanning a variety of technologies. He focuses on designing and building of large-scale enterprise applications. He is also an internationally acclaimed speaker, speaking at over 100 developer conferences worldwide, delivering more than 600 talks. Check out his web site at http://www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.
nford@thoughtworks.com | Fast Facts | | Developers do polyglot programming all the time without even realizing it. Do you write applications that talk to a database? Do you write Web applications? Chances are good that you do, which means that you are already polyglot programming. | |
Aspect-Oriented Programming Origins
This concept was introduced in 1997 in a paper by Gregor Kiczales and others in the Proceedings of the European Conference on Object-Oriented Programming, vol.1241 |