In this panel recorded during OOPSLA 2008, the panelists, Jeff Gray (moderator), Kathleen Fisher, Charles Consel, Gabor Karsai, Marjan Mernik, Juha-Pekka Tolvanen, talk about the benefits and drawbacks of using DSLs.
Watch: DSLs: The Good, the Bad, and the Ugly (1h 30min)
Kathleen Fisher, AT&T Labs Research, talks about Hancock, a DSL written in C for creating customer signatures based on their transactions. The idea is to try to determine each customer’s behavior for placing international calls. International calls are monitored and if a call does not follow the usual behavior for the supposed customer, then a fraud alert is triggered. This is necessary because of the large number of fraudulent calls placed for customers who did not actually made those calls. Fisher presents the benefits and also the drawbacks of a DSL like Hancock.
Charles Consel, University of Bordeaux and INRIA, said that what’s important when creating a DSL is to “really understand the domain and to work on the design of the language.” When writing a DSL that’s going to be used by external customers, it is important to see what determines those customers to adopt that particular DSL. Most customers he has talked to want an abstraction layer (the DSL) helping them to get faster and easier to the solution for their problem. On the negative side, Consel mentions the difficulty in creating another DSL, for a different domain, starting from a successful and existing one. He considers that happens because we don’t have the tools to automate the domain analysis process.
Gabor Karsai, Vanderbilt University, considers that DSLs are good for providing abstractions of domains. The problem with DSLs is that they are usually proprietary and the knowledge encapsulated in them is not available to others. Karsai said that usually people consider that having a DSL and a visual tool coming with it will solve their problem, not realizing that they still need to design the application the DSL is targeted for. DSLs won’t help anyone who does not take good care of the application design.
Marjan Mernik, University of Maribor, complained about using a too narrow definition of what DSLs are, like being only modeling languages. They are specification, modeling and programming languages. Another problem is the accepted definition of a domain, like scripting or parallel programming. Mernik considers that such domains are not enough specialized to be considered domains for a DSL. The greatest strength of DSLs is the analysis, verification, optimization, parallelization, and transformation of the domain.
Juha-Pekka Tolvanen, MetaCase, has been involved in the development of about 100 DSLs for automotive, home appliances or mobile phone industries, and also banks. He is the industry and tool vendor voice in the panel. He mentions the following benefits of using DSLs: quality, detecting errors early in the development phase, leveraging the accumulated expertise, hiding the complexity. The greatest benefit is productivity, according to Tolvanen. Developers can create a lot more a lot faster by using a good DSL that highly abstracts the underlying domain. One of the problems encountered working with customers is that they create DSLs that are too general and have difficulties narrowing them enough to represent only their specific domain. A mistake is when the low level characteristics of a language are imported into the DSL, like the visibility of parameters, resulting in a granular language that resembles too much the underlying programming language. An advice: using LEX and YACC to build DSLs is a waste of time. Special tools should be used instead.
The second half of the session was dedicated to commentaries and questions.
