Kyle Huntley

Domain Specific Language (DSL) is a technique for crafting a special-purpose languages to create solutions within a specific and well-defined problem space.  The potential is immense.  They may be a little over-hyped (in some circles), and I think we’re still a ways from business analysts writing their own systems…

Nevertheless, I assert that DSLs are important and will increase in popularity and utility as the tooling improves to allow “DSLs for the masses”.  SQL, HTML, XAML, UI and Process design surfaces.  These are all examples of DSLs and all revolutionary in power and productivity.

I’m of course not advocating that everyone build a new DSL for every project, but when there are “product families” which share a problem space, the power of DSLs is undeniable.

The power of DSLs comes from working with high level code elements that are “abstract” but not “imprecise”.  It’s like one of these trade-off triangles.  Everybody knows the scope-staff-schedule triangle.  You can hold two fixed, but at least one must move.

With DSLs, the triangle is abstraction-precision-domainScope.  If the domain is huge or unbounded, you have to choose between abstraction and precision.  This really limits the power of the abstraction, because it can’t be fully precise and is therefore not “code” – not executable even in theory [1].  However, if you limit the scope of the domain, you can raise the level of abstraction without losing precision.  This - in a nutshell - is the “magic” of DSLs.

[1] This is closely related to the Platform Independent Model (PIM) fallacy, but that is another tale. 

At the risk of not only stating the obvious, but also sounding like a prognosticating blowhard… I’d say that developers with a skill-set that only involves programming to a spec should worry about being automated out of their jobs.  This has happened countless times through our history of near-continuous economic revolution and there’s no reason to believe that it can’t happen with software.  (that was the blowhard part) The frameworks we code against have increased in sophistication and utility a tremendous amount over the last decade, and the previous decade for that matter, though it seems to be accelerating.  What was once many lines of code is now few and I expect this trend will continue.  Add to that the coming (this is the prognosticating bit) rise of domain specific languages and you can see that the design and the code will be converging and folks who make their living off the current delta are going to feel the squeeze. 

 Blog Help

Some thoughts about the boundary between what we traditionally think of as thin and thick client apps.  With the increasing complexity of the browser environment I think the distinction is blurring between using a browser as an execution host vs. a “traditional” run-time as an execution host.

In the beginning there was the native client, and it was good.  For a while at least, until IT departments found out how expensive it was to maintain that software configuration.

So came the radical shift towards thin client, with a goal of zero client side application footprint.  There were two options:

·         Distribute a runtime and enable it to run network portable code.  Like Java and Applets.

·         Use a browser and send lightweight markup over the network.

Well, at the time there were problems with the runtime approach:

·         Distributing the Java runtime was problematic for many network connections.

·         Applets were painfully, agonizingly, slow in execution

·         The applets were also relatively big for the network (then) to carry.

So, momentum shifted to the browser model.

Well the browser was small and fast, and the markup was light, but it couldn’t really do that much.  Accordingly, the industry spend a decade or so enhancing the browser object models and environments until the browsers became runtimes in their own right, which are capable of hosting reasonably complex software that just happens to be JIT-Loaded from a web server, taking us to Atlas / Ajax today.

Atlas / Ajax does not represent any “Best Practices” in development from a purely technical standpoint; there are better ways to do it all.  It is the unfortunate reality that the industry has been unable to settle on a single well-conceived runtime environment and has instead taken a drunkard’s walk to arrive at a very unappealing, but relatively standard, programming environment.  Ajax is simply a way of trying to paper over the “poor” client characteristics of the browser / markup technology rootstock.

If we re-examine the runtime vs. browser decision today, would we make the same decision?

·         Browser downloads are now comparably sized to full-fledged runtimes and networks are much faster, so the browser no longer has any clear advantage in runtime distribution.

·         “Applets” or transportable .NET code is plenty fast for the client now, so that reason favoring the browser is also gone.

·         Downloaded byte-code or IL can still be pretty big.  This can be managed with proper techniques, but it is still nowhere near as light as interpreted script and markup.

So it seems that the size of the executable is the last strong fundamental reason to favour the browser model.  This must be balanced against the inferior programming model.

With new markup-enabled rich client technologies, such as WPF and Silverlight, the applications distributed to the client side run-times will be light enough, but with good user experience plus properly robust and productive development models.  This should knock the final pin out from under the browser approach.  From both a user and a developer standpoint I look forward fondly to a day where I don't have to submit to the tyranny of the back button.  ;-)