jump to navigation

Are Domain-Specific Languages the Next Software Engineering Breakthrough? November 11, 2010

Posted by Peter Varhol in Software development, Software platforms, Software tools.
trackback

Almost since people have been writing software, we’ve looked for better, more efficient, and more intuitive ways of doing it.  First-generation languages (machine code) gave way to second-generation languages (assembly), which was largely abandoned in favor of third-generation languages that are in mainstream use today.  Starting with the likes of Fortran and Cobol in the late 1950s, we now use C# and Java, plus a number of other less mainstream but still-important third-generation languages.

That’s not to say that we haven’t tried growing beyond the third generation.  For a while in the 1990s, fourth-generation languages like PowerBuilder and Progress attempted to make data access more intuitive.  Also in the 1980s, Japanese industry and academia embarked upon a far-reaching but poorly-understood Fifth-Generation Computing project that didn’t have any wide-ranging impact on software development.

And C# and Java represent a significant advance over the likes of C++ and Ada in that they are managed languages.  Rather than requiring the programmer to manually write code to allocate and deallocate computer memory, the underlying language platform does it automatically.

But at a conceptual level there’s little else fundamentally different between Fortran and C#.  To be clear, there is much that is different, but the language instructions themselves haven’t changed a whole lot.  While we have libraries and frameworks that enable us to abstract a bit more today (and doing so may create more problems), we are writing code as the same conceptual level that we did fifty years ago.

The buzz in the industry over the last several years has surrounded so-called domain-specific languages, or DSLs.  I’m reminded of this by this article on former Microsoft executive Charles Simonyi, who has since founded a company to create a foundation for implementing DSLs.  I’ve also participated in several conferences over the last couple of years where speakers have promoted DSL concepts.

DSLs are an attractive concept for a number of reasons.  Because they focus on a specific problem domain, they tend to be fairly simple.  Domain experts, rather than programmers, may be willing to adopt them because they abstract a programming problem into terms that they understand, and can build solutions for.

I really like the idea, but I’m doubtful in practice.  Fifteen-plus years ago as an academic, I actually wrote a DSL, a visual language for discrete event simulation.  I loved it, but even those interested in discrete event modeling were flummoxed at some of the things I did.  And these were people who were used to thinking in those terms.  Languages meant for specific types of problems have to be designed very carefully (I probably didn’t do that) just in order to appear on the radar.

And I think we’ve debunked the concept of the citizen programmer.  I’ve seen a lot of products intended to bring programming to the user come and go over the last twenty years.  Microsoft’s original Visual Basic was intended to do just that, but it was successful only because it was useful to professional programmers.  While a few domain experts adopted 4GLs and became programmers (I saw that while working at Progress Software), it’s very much an exception.

We prize programming languages in large part for their versatility, not their simplicity or their utility for a specific purpose.  DSLs aren’t flexible.  Even in a problem domain, you want the ability to draw in instructions and tools from other domains, and from a large toolkit in general.  Unless we rethink the fundamental concepts behind DSLs, this will be the next breakthrough that never was.

Advertisements

Comments»

1. Can Everyone Learn to Code? « Cutting Edge Computing - November 29, 2011

[…] Domain specific languages (DSLs) also have the potential to make programming easier.  Languages like LabView and Simulink let engineers create data acquisition and simulation applications without writing a line of code. […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: