A Jerk in the Land of a Hundred Languages

There is an article in this week’s Economist referring to a paper by Dr. Mark Pagel et al published in the latest edition of Science on (spoken) languages evolving in punctuational bursts. The key point in Dr. Pagel’s research is that evolutionary change happens in sudden jumps separated by long periods of creeping evolution. The article uses the huge differences in the written language of the English writers Geoffery Chaucer and William Shakespeare who lived two centuries apart. You’ve probably read, and understood, Mr. Shakespeare’s writing, but how about Mr. Chaucer?

This frere bosteth that he knoweth helle, And God it woot, that it is litel wonder; Freres and feendes been but lyte asonder. For, pardee, ye han ofte tyme herd telle How that a frere ravyshed was to helle In spirit ones by a visioun

The article got me thinking about DSLs and our hundred language future. Grady Booch once said that “They [programming languages] tell us about the state of software practice, the minds of their inventors and the technical, social, and economic forces that shaped history at the time. They’ll provide the raw material for software archaeologists, historians, and developers to learn what worked, what was brilliant, and what was utter failure.” Through-out my entire career as a software professional C/C++, Java, Visual Basic and C# have been dominant within the industry. Some undercurrents, such as Python, have always been there, and recently these undercurrents have become many and grown stronger. One of the driving forces behind this is the growing interest in domain specific languages, not only custom languages built by developers to tackle narrow business problems, but also more general purpose languages that are suited to address different programming problems. Today’s, and not to mention tomorrow’s, programming profession some what seems to resemble the scene in the 1980s. At this time I was programming BASIC, Pascal and assembly language. Other people I knew where into C or ADA, while most professional programmers did COBOL or Fortran. Anyone working with legacy applications know that it can be rather cumbersome to integrate and evolve applications written in this plethora of languages, so why do I welcome a future of “a hundred languages”? First, todays flurry of languages build on a different fundament than in the eighties. At that time different languages where different platforms, while today most of the languages are available in some form for both Microsoft’s CLR and the Java VM so we won’t be experiencing the same challenges with getting something written in Python to play nice with something written in C#. In fact, I believe that this is a key reason for more and more developers becoming polyglots, having a common platform allows you to use your knowledge of that platform and its frameworks and at the same time choosing the language that is best suited for the task at hand.

So what about the sudden jerks in language evolution? If you look at the two dominant programming languages for the last decade, they are really just different dialects of the C language which has had a strong presence since the mid 70’s. Using Dr. Pagel’s terms, this has been a creeping evolution. If we look at the new kids on the block; languages such as Boo, Groovy or Scala we see languages that absorb the abilities of quite different languages. Both Boo and Groovy have similarities to Python, but at the same time they also have elements of C# or Java in them. Scala builds on Java, but at the same time it brings a little Objective Caml into the mix. Even if it’s not a particularly “new” language, Ruby needs to be mentioned as well. This language has similarities to Python, Perl, Smalltalk and quite a few other languages. These languages abilities to absorb the good from other, well established languages is what makes them interesting choices when the CLR or VM allows us to do so. A common theme for all of these “new” languages is that they are more flexible than their predecessors and this appeals to many programmers. The features that make them so flexible feed back into their ancestors and is fueling change in these as well. Just look at the huge leap C# made in its latest incarnation and the number of proposals for new features in the next version of Java. I think this can very well be a jerk in language evolution.

Will future programs be as hard to read using todays skills as the excerpt from Chaucer’s Summoner’s Tale? I think it depends on what you’ve experienced before. As Steve Yegge put it, one-trick ponies only know one trick. If you’ve only written Java or C# code, you would be searching desperately for if, switch, for and while statements in Erlang.

% This could be a for(int i = 1; i <= 10; i++)
% in Erlang...
f(m,m,F) -> [F(m)]
f(I,m,F) -> [F(I)|f(I+1,m,F)]
f(1,10,F)

On the other hand, you could find developers choosing to use Simula to write a fitting room simulator it might be easier to grasp than the same thing in C#.

Simulation Begin
   Class FittingRoom; Begin
      Ref (Head) door;
      Boolean inUse;
      Procedure request; Begin
         If inUse Then Begin
             Wait (door);
             door.First.Out;
         End;
         inUse:= True;
      End;
      Procedure leave; Begin
         inUse:= False;
         Activate door.First;
      End;
      door:- New Head;
   End;

   Procedure report (message); Text message; Begin
      OutFix (Time, 2, 0); OutText (": " & message); OutImage;
   End;

   Process Class Person (pname); Text pname; Begin
      While True Do Begin
         Hold (Normal (12, 4, u));
         report  (pname & " is requesting the fitting room");
         fittingroom1.request;
         report (pname & " has entered the fitting room");
         Hold (Normal (3, 1, u));
         fittingroom1.leave;
         report (pname & " has left the fitting room");
      End;
   End;

   Integer u;
   Ref (FittingRoom) fittingRoom1;

   fittingRoom1:- New FittingRoom;
   Activate New Person ("Sam");
   Activate New Person ("Sally");
   Activate New Person ("Andy");
   Hold (100);
End;

Even if this is just plain old Simula, it resembles many of the examples you find of domain specific languages - but then again, Kristen Nygaard wrote Simula to make it easier to simulate the operations of systems, so in a sense it was a DSL. DSLs written by developers to tackle narrow business problems are likely to be built on top of general purpose languages such as Ruby or Boo who lend themselves easily to this, or using a common language workbench infrastructure such as Microsoft’s Dynamic Language Runtime. If you’re proficient with these, you’ll probably be able to maintain our futures polyglot applications - it won’t be much different from maintaining an application that uses a variety of frameworks written in a single language. The most noticeable difference might be that you won’t feel like your forcing the square peg trough the star shaped hole as often as you do today, at least if you’ve chosen the right language for the job.

Now Playing: Chris Kenner - Land of a Thousand Dances