Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Saturday, January 07, 2012

Trapped

DSLs are currently being promoted by a large number of activists. If you ever read the seminal Pragmatic Programmers book, you'll also find such a recommendation there. So, will the software engineering universe soon turn into a paradise? Let me tell you two examples from industrial practice: Once upon a time, in the logistics domain, a smart and lazy software engineer introduced a new language just for himself, in a very ad-hoc manner. When they saw the result, all his colleagues got very excited about the concept and started extending the language for their own purposes. The language inevitably grew and grew. Soon, an increasing number of system parts were depending on the language. Unortunately, when our smart inventor reached a high age, he had to leave and let his colleagues alone. But now, there was no one left in the company who really understood the language concept and its realization. It is claimed that the language keeps still growing. Other theories assume the system had to be completely rewritten in the meantime. In another universe and another time, another software engineer was convincing his fellows to introduce DSLs. All the IT dwarfs went crazy inventing their own languages. Yes, they even made competitions who could come up with the most fasinating or useful language. After a while, the DWARF software system was nothing but an ocean of languages. Only wizards were able to generate a working solution. When a furious dragon (= customer) attacked their town, everything imploded. No one has a clue where the remains of the dwarf town are located. What can we learn from these failures? DSL design is (like) architecture design. An ad-hoc language will lead to design erosion, and cause more harm than good in the long run. DSLs represent strategic design tools that should only be in the hands of experienced designers. There are purposes for which DSLs are a perfect fit. But there are also circumstances where they shouldn't be applied. Overdoing it increases accidental complexity. It is like component-based re-use. Each DSL should only have one responsibility. Plan to grow the DSLs systematically, refactor it and verify its correctness. Communicate with all stakeholders that are affected by the DSL. Consider the design choices for the language syntax. Should it be a text-based language, a graphical language, or both? Mind the XML hell - long, long ago almost everyone was striving for XML based languages. But in some rare contexts XML made writing configurations and documents ineffective, uncomprehensible, and tedious. I've seen systems wirh thousands of XML files. Let experts build and grow languages. It is amazing how (often) our discipline gets addicted to all kinds of panacea. Once you are lost in the buzzword jungle, all systems and stakeholders will suffer fom DSL paranoia. DSLs are an awesome means for boosting productivity. However, used by the wrong persons or with the wrong motivations, it is easy to shoot yourself in the foot.

5 Comments:

  • Dear Michael,
    you are perfectly right on this. DSLs can be powerful, but are not the every-time, every-where solution.

    I also tried to explain that recently in a post of mine. Let's hope that wanna-be language developers hear our voice :)

    You can see my point here:

    http://www.modeldrivenstar.org/2011/02/building-dsl-who-how-and-when.html

    By Blogger Unknown, at 11:04 AM  

  • By Anonymous Shahzad, at 8:57 PM  

  • I do not understand why there's any steam left today in the DSL discussion. We already started it 17 years ago, and go pretty much nailed down as an engineering technique in the 2000's. Use it as any other pattern.

    By Blogger ACV ModelDD, at 7:04 PM  

  • I want to take this moment to say that I really love this blog. It has been a good resource of information for me. Thank you so much

    By Anonymous vinyl covers for equipment, at 9:03 AM  

  • Nice post.
    XML as part of DSL design? DSL design should aim to simplify describing a solution in a certain domain. Simplification of description always comes with readability. This should rule out XML entirely..

    Another important aspect of using DSLs in production environment. Or better extending and changing DSLs is dealing with the existing code base. A kind of version management or migration strategy has to be established from the beginning..

    By Blogger Andreas Pokorny, at 7:35 PM  

Post a Comment

<< Home