Posted by: Joe Brinkman
4/1/2009 2:02 PM 

In 2006, Neal Ford wrote a blog post on the topic of Polyglot Programming which foresaw a future where applications will be increasingly built using multiple general purpose languages and domain specific languages.  Ted Neward has a recent article from MSDN Magazine which follows up on this theme with a discussion of Polyglot Programming in .Net.  Both Neal and Ted address some of the issues with Polyglot Programming, but I think there is one that they have missed.  Polyglot Programming can quickly lead to performance rot in application development.

In DNN Tips and Tricks #10, I presented an example of how you can use the DotNetNuke Report Module to display you data using the advanced capabilities of XSLT.  Greg Lahens pointed out an issue with my SQL code which is really highlights one of the downsides to Polyglot Programming.  As programmers, we often employ a variety of tools to solve a particular programming challenge.  Many of these tools are DSLs – XSLT, SQL, CSS, HTML are just a few of the many DSLs in common use throughout the web development world. 

The problem comes into play in that few developers have the luxury of being an expert in every DSL they use.  Most developers I know, are extremely proficient in their primary language – whether it is C#, VB, Java, Ruby or whatever.  Those same developers will often have a working knowledge of the secondary languages and DSLs used in their day to day programming.  Yet the number of DSLs is rapidly expanding.  We have DSLs for styling applications (a different one depending on whether it is Silverlight/WPF or Html), a DSL for transforming data, a DSL for querying data (possibly multiple DSLs for a single depending on how much you trust your ORM), a DSL for searching some text element, and even a DSL for merging our data with our presentation structure and styles, and several DSLs for exposing our data in a raw format to users.  After learning all those DSLs, I then have a handful of additional DSLs to learn to build my application, package it into an installation package, and possibly one more for building the Help files.  Ohh wait.  You are doing automated unit testing right?  You’ll need another couple of DSLs for that.  And let’s not forget the DSL that we use for configuring the application after it is deployed.

I don’t know about other programmers, but I am drowning in DSLs.  It is hard enough keeping up with my primary development language and the associated platform APIs, but these DSLs are going to be the death of me.  The end result is that I have a pretty decent handle on maybe 3 or 4 of these DSLs but rarely do I have the requisite knowledge to make the right choices in anything beyond that.  Yes I know SQL.  But as Greg Lahens pointed out in my last post, it leaves a lot to be desired in terms of performance.

Now some might argue that SQL should be handled by a DBA who specializes in SQL.  That is great.  I know have 14 DSLs instead of 15 to learn.  Oh wait.  Sorry, I have just been informed that we don’t have a budget for a dedicated DBA.  So I guess the requests for dedicated XSLT, CSS, and Regex developers probably are not going to be approved either.  In most of the development shops I have worked in, the developer has no choice but to learn many of these DSLs.  Most projects are not large enough to warrant the use of specialists, however almost every project demands great performance and minimal bugs.  One false move in your CSS, XSLT, Regex, JavaScript, SQL or any of the other DSLs in use and you will severely impact the performance of your application. 

What is worse is that the methods and tools used for testing performance in each DSL is often vastly different.  I have great tools to help me profile my VB/C#/Java code.  Not so much when it comes to CSS, JavaScript, XSLT or many of the other DSLs in use.  And even when good profiling tools exist, learning to use them often requires a significant time investment.

I don’t know the ultimate solution to this problem, but I do know that every day it is only getting worse.  The Computer Science community is cranking out languages and DSLs at a rapid pace.  On top of that we continue to evolve our development methodologies and architectures such that the average programmer is left wondering how they can possibly keep up.  Sure, the alpha geeks among us will be able to grok it all and crank out applications using the latest DSLs, but the average developer (who make up the vast majority of the programming resources building application today) is being marginalized more and more. I believe that DSLs have their place and certainly provide a lot of value, however we need to take a hard look at where we are going in this profession.  I believe we need to find solutions that meet programmers “where they live” and not “where we want them to be”, by this I mean we need to find solutions to our CS problems that recognize that not all programmers are computer scientists.  Not all programmers have the time or motivation to learn 15 different DSLs just to create an application.  Not all programmers want to learn a new programming methodology because the old methodology is no longer en vogue.  We need to simplify what we are doing so that it doesn’t take an army of specialists to build a decent application.

Trackback Print

Tags:

Categories:

Location: Blogs Joe Brinkman