This document describes a master's thesis that develops multiple interacting domain-specific languages (DSLs) to model different technical domains for the purpose of generating a complete Java-based web application. It aims to increase productivity and quality by abstracting away implementation details and focusing on domain concepts. The thesis will develop DSLs for modeling domain data (generating JPA), modeling the view side of web applications (generating Seam/JSF/Facelets), and modeling domain-specific business rules. It explores whether multiple interacting DSLs are feasible and how their interaction should be implemented.

1. Developing Interacting Domain Specific Languages
Developing Interacting Domain Specific Languages
Master’s thesis
Sander Mak
Center for Software Technology, Universiteit Utrecht
October 25, 2007
Supervisor : Doaitse Swierstra
Daily supervision : Bastiaan Heeren
Eelco Visser
Center for Software Technology Sander Mak

2. Developing Interacting Domain Specific Languages > Introduction
Outline
Introduction
1
DomainModel
2
WebLayer
3
Interaction
4
Reflection
5
Conclusion
6
Center for Software Technology Sander Mak

3. Developing Interacting Domain Specific Languages > Introduction
Domain Specific Language
Increased productivity
Increased quality
Advantages:
Clarity by abstraction
Center for Software Technology Sander Mak

4. Developing Interacting Domain Specific Languages > Introduction
Languages?
Why the plural, i.e. DSLs
Center for Software Technology Sander Mak

5. Developing Interacting Domain Specific Languages > Introduction
Languages?
Why the plural, i.e. DSLs
One-size fits all, monolithic
approaches generally not
succesful (like 4GLs)
Separation of concerns, and:
reusability of DSL in other
contexts
Premise: Technical domains are a
good unit of composition
Center for Software Technology Sander Mak

6. Developing Interacting Domain Specific Languages > Introduction
Languages?
Why the plural, i.e. DSLs
One-size fits all, monolithic
approaches generally not
succesful (like 4GLs)
Separation of concerns, and:
reusability of DSL in other
contexts
Premise: Technical domains are a
good unit of composition
Center for Software Technology Sander Mak

7. Developing Interacting Domain Specific Languages > Introduction
Languages?
Why the plural, i.e. DSLs
One-size fits all, monolithic
approaches generally not
succesful (like 4GLs)
Separation of concerns, and:
reusability of DSL in other
contexts
Premise: Technical domains are a
good unit of composition
Research questions:
Are multiple interacting DSLs feasible?
1
How should interaction be concretized and implemented?
2
Center for Software Technology Sander Mak

8. Developing Interacting Domain Specific Languages > Introduction
The case study
DomainModel Modeling domain data, generating
JPA (similar to Hibernate) implementation
WebLayer Modeling the view side of web-applications,
generating Seam/JSF/Facelets
BusinessRules Modeling functionality specific to a domain
Different compilers, one goal: build a complete Java based web-app
Center for Software Technology Sander Mak

9. Developing Interacting Domain Specific Languages > Introduction
Goals
Why create DSLs for these domains:
Increase productivity
Abstract away from implementation details, focus on domain
concepts (also gives more clarity)
Java frameworks are (inherently?) verbose
Increase quality
Dynamic, interpreted mechanisms subvert static safety of Java code
Report domain specific errors
Center for Software Technology Sander Mak

10. Developing Interacting Domain Specific Languages > Introduction
Goals
Why create DSLs for these domains:
Increase productivity
Abstract away from implementation details, focus on domain
concepts (also gives more clarity)
Java frameworks are (inherently?) verbose
Increase quality
Dynamic, interpreted mechanisms subvert static safety of Java code
Report domain specific errors
What is explicitly not our goal:
creation of production quality languages,
unleashing every bit of power of target frameworks
Center for Software Technology Sander Mak

11. Developing Interacting Domain Specific Languages > Introduction
Goals
Why create DSLs for these domains:
Intended use
Increase productivity
To create data-intensive web-applications, focus on confines of
within domain
Abstract away from implementation details,
company guidelines. gives more clarity)
concepts (also
Java frameworks are (inherently?) verbose
Increase quality
Dynamic, interpreted mechanisms subvert static safety of Java code
‘You can’t be everything to everyone,
Report domain specific errors
so be something for someone’
What is explicitly not our goal:
creation of production quality languages,
unleashing every bit of power of target frameworks
Center for Software Technology Sander Mak

12. Developing Interacting Domain Specific Languages > DomainModel
DomainModel language
Language for defining persistent domain (or data) models
Essential features:
Concise definition of concepts (entities)
Generates JPA implementation (standardized library)
Encodes domain specific technical knowledge (e.g. object identity)
Allows for domain specific semantic checking
May be used in combination with different DSLs
Center for Software Technology Sander Mak

13. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Center for Software Technology Sander Mak

14. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Types: Value, Extended (validated), Concept, List, Enumeration
Center for Software Technology Sander Mak

15. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Types: Value, Extended (validated), Concept, List, Enumeration
Center for Software Technology Sander Mak

16. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Types: Value, Extended (validated), Concept, List, Enumeration
Center for Software Technology Sander Mak

17. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Types: Value, Extended (validated), Concept, List, Enumeration
Center for Software Technology Sander Mak

18. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Types: Value, Extended (validated), Concept, List, Enumeration
Center for Software Technology Sander Mak

19. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Associations: Value, Reference, Composite
Center for Software Technology Sander Mak

20. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Associations: Value, Reference, Composite
Center for Software Technology Sander Mak

21. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
Associations: Value, Reference, Composite
Center for Software Technology Sander Mak

22. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
DomainModel annotations
Center for Software Technology Sander Mak

23. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
contents :: String (required)
user -> User
date :: Date (name)
tags -> [Tag]
replies <> [Reply]
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
DomainModel annotations
Center for Software Technology Sander Mak

24. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
title :: String (name, required)
abstract :: String
Compiling a DomainModel concept
contents :: String (required)
Definition -> User
BlogEntry results in BlogEntry.java, a
user
persistable:: Date
JPA entity: (name)
date
tags -> [Tag]
replies <> [Reply]
268 LoC
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
trackback :: URL
}
DomainModel annotations
Center for Software Technology Sander Mak

25. Developing Interacting Domain Specific Languages > DomainModel
Concept definition
concept BlogEntry {
Q: Isn’t DomainModel almost the same as UML Class diagrams?
title :: String (name, required)
A: Yes!
abstract :: String
contents :: String (required)
userWe even ’borrowed’ some of the association symbols
-> User
date ’− :: Date
>’ for references (name)
’<>’ for composites
tags -> [Tag]
replies way, prior UML knowledge helps when using
<> [Reply]
That
category :: {quot;Technicalquot; : TECH, quot;Otherquot; : NONTECH}
DomainModel
trackback :: URL UML class diagram could serve as input for
Theoretically, a
} the DomainModel compiler (if only we had a UML
front-end)
DomainModel annotations
Center for Software Technology Sander Mak

26. Developing Interacting Domain Specific Languages > WebLayer
WebLayer language
Language for defining pages (views) in web-app
Essential features:
Works seamlessly with DomainModel definitions
Abstracts away from the Seam framework and Java intricacies
Strongly typed
Explicit, checked data-flow between pages
Generic constructs
Center for Software Technology Sander Mak

27. Developing Interacting Domain Specific Languages > WebLayer
WebLayer compiler
Center for Software Technology Sander Mak

28. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

29. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

30. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
Multiple page definitions in one file, starting with a header:
var Reply r
weblayer blog
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
using domainmodel blog{ quot;Assigned tagsquot; -> t.tagName }
table Tag t in be.tags
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

31. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

32. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

33. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

34. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

35. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

36. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
quot;Reply to this post:quot;
form( input(r)
action( quot;Add replyquot;
, r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

37. Developing Interacting Domain Specific Languages > WebLayer
Page definition
page ViewBlog(BlogEntry be, User u){
var Reply r
header(be.title + quot; (written on quot; + be.date + quot;)quot;)
text(be.contents)
Ideas for extension
table Tag t in be.tags { quot;Assigned tagsquot; -> t.tagName }
Query language
quot;Reply to this page abstraction
Partial post:quot;
form( input(r)
Parameterized, reusable actions
action( quot;Add replyquot;
... , r.user = u; be.replies.add(r); be.save())
)
text(quot;Replies for post quot; + be.title + quot; :quot;)
for Reply r in be.replies { show(r) }
navigate(quot;Homequot;, Blog(u))
}
Center for Software Technology Sander Mak

38. Developing Interacting Domain Specific Languages > WebLayer
Issues
Layout is more or less fixed
Example: every page element is placed beneath each other
We don’t want to replicate all of HTML inside WebLayer
Partial solution: embed generated page in freely editable template
For the rest: make assumptions, although compiler becomes more
specific
Editing lists
Our solution is specific and ad-hoc
Action language
Why not, for example, embed Java?
Center for Software Technology Sander Mak

39. Developing Interacting Domain Specific Languages > Interaction
DSL Interaction
We can use DomainModel constructs within WebLayer, but how does
this interaction work?
Goals
Interaction must be intuitive to DSL user
Languages must be as separate as possible
For the sake of reusability
Generated code must statically link
Center for Software Technology Sander Mak

40. Developing Interacting Domain Specific Languages > Interaction
DSL Interaction
We can use DomainModel constructs within WebLayer, but how does
this interaction work?
Goals
Interaction must be intuitive to DSL user
Languages must be as separate as possible
For the sake of reusability
Generated code must statically link
Our solution
Separate compilation for each DSL, communicating essential
information through interface files.
Center for Software Technology Sander Mak

41. Developing Interacting Domain Specific Languages > Interaction
DSL Interaction
Separate compilation illustrated
We can use DomainModel constructs within WebLayer, but how does
this interaction work?
Goals
Interaction must be intuitive to DSL user
Languages must be as separate as possible
For the sake of reusability
Generated code must statically link
Our solution
Separate compilation for each DSL, communicating essential
information through interface files.
Center for Software Technology Sander Mak

42. Developing Interacting Domain Specific Languages > Interaction
Interface files
DSL compiler emits interface file. We chose ATerms as generic
representation format.
Interface characteristics
Aggregates information
Contains disambiguated information
Contains linking information (types, hooks)
Written interface guarantees a consistent, checked module to be
present
Center for Software Technology Sander Mak

43. Developing Interacting Domain Specific Languages > Interaction
Interface files
DSL compiler emits interface file. We chose ATerms as generic
representation format.
Interface characteristics
Aggregates information
Contains disambiguated information
Contains linking information (types, hooks)
Written interface guarantees a consistent, checked module to be
present
One way to view interface file mechanism is as cache for compiler
operations
Center for Software Technology Sander Mak

44. Developing Interacting Domain Specific Languages > Interaction
Interface files
DSL compiler emits interface file. We chose ATerms as generic
representation format.
Interface characteristics
Aggregates information
Q: Why cache, are these operations so expensive?
A: No, not at all. The information the importing compiler
Contains disambiguated issue is that
otherwise needs toinformation (types, hooks)
Contains linking know how to perform these operations. We
don’t want that, since it breaks our notion of modular interacting
Written interface guarantees a consistent, checked module to be
languages!
present
One way to view interface file mechanism is as cache for compiler
operations
Center for Software Technology Sander Mak

45. Developing Interacting Domain Specific Languages > Interaction
Interface files
DSL compiler emits interface file. We chose ATerms as generic
representation format.
Interface characteristics
Aggregates information
Contains disambiguated information
Contains linking information (types, hooks)
Written interface guarantees a consistent, checked module to be
present
One way to view interface file mechanism is as cache for compiler
operations
Issues: explicit vs. implicit interface, cyclic dependencies between
DSLs
Center for Software Technology Sander Mak

46. Developing Interacting Domain Specific Languages > Reflection
Does this approach really work?
Promises of model driven software development:
Gain productivity
Gain quality
... so do we live up to this expectation?
Center for Software Technology Sander Mak

47. Developing Interacting Domain Specific Languages > Reflection
Does this approach really work?
Promises of model driven software development:
Gain productivity
Gain quality
LoC metrics - Blog example ... so do we live up to this expectation?
DSL Source Generated code
DomainModel 45
Java 801
XML 22
WebLayer 110
Java 841
XML/Facelets 501
XML 48
∼ ×14
Totals 155 2213
Center for Software Technology Sander Mak

48. Developing Interacting Domain Specific Languages > Reflection
Does this approach really work?
Promises of model driven software development:
Gain productivity
Gain quality
... so do we live up to this expectation?
Productivity:
1 The factor ∼14 increase in LoC seems to be typical
2 DRY: refactoring in DSL code is much easier
3 Start-up costs manageable
Center for Software Technology Sander Mak

49. Developing Interacting Domain Specific Languages > Reflection
Does this approach really work?
Promises of model driven software development:
Gain productivity
Gain quality
... so do we live up to this expectation?
Productivity:
1 The factor ∼14 increase in LoC seems to be typical
2 DRY: refactoring in DSL code is much easier
3 Start-up costs manageable
Quality:
1 DSL Type checker guarantees correctness of dynamic
constructions (and there’s much of that in Java web frameworks!)
2 Typed, explicit dataflow between pages
3 Concrete example: guaranteed prevention of cross-site scripting
Center for Software Technology Sander Mak

50. Developing Interacting Domain Specific Languages > Reflection
Drawbacks of our approach
Every semantic check must be written from scratch
For each DSL
Type checking, resolving symbolic references, and so on
Fortunately, we can get very specific with our checks and
associated messages
Center for Software Technology Sander Mak

51. Developing Interacting Domain Specific Languages > Reflection
Drawbacks of our approach
Every semantic check must be written from scratch
For each DSL
Type checking, resolving symbolic references, and so on
Fortunately, we can get very specific with our checks and
associated messages
Module system must be written from scratch
This might be solved generically (parameterizing over interface
definitions), though we have not researched this
Center for Software Technology Sander Mak

52. Developing Interacting Domain Specific Languages > Reflection
Drawbacks of our approach
Every semantic check must be written from scratch
For each DSL
Type checking, resolving symbolic references, and so on
Fortunately, we can get very specific with our checks and
associated messages
Module system must be written from scratch
This might be solved generically (parameterizing over interface
definitions), though we have not researched this
What are the semantics of our DSLs?
Center for Software Technology Sander Mak

53. Developing Interacting Domain Specific Languages > Reflection
Alternative approaches
Embedded DSLs
Asynchronous, runtime linking of generated code (independent
code generation)
Larger role for the IDE
Long-term: active libraries and a universal language
Center for Software Technology Sander Mak

54. Developing Interacting Domain Specific Languages > Reflection
Alternative approaches
Embedded DSLs
Asynchronous, runtime linking of generated code (independent
code generation)
Larger role for the IDE
Long-term: active libraries and a universal language
Realistically, this probably never happens
Center for Software Technology Sander Mak

55. Developing Interacting Domain Specific Languages > Conclusion
Demonstration
Center for Software Technology Sander Mak

56. Developing Interacting Domain Specific Languages > Conclusion
Topics not discussed
... but interesting nevertheless
Actual implementation details of compilers
1
Implemented using Stratego/XT toolkit
BusinessRules interface definition
2
To overcome limitations of WebLayer action language in multiple
DSL style
Interaction with GPL code
3
Necessary for real-world adoptation, but how to implement it?
Much more context and related work
4
... my thesis will be available shortly
Center for Software Technology Sander Mak

57. Developing Interacting Domain Specific Languages > Conclusion
Concluding remarks
Interacting DSLs indeed feasible
Especially suited for layered architectures (like web-applications)
DSLs encode principled usage of frameworks and framework
interaction
Interaction implemented through interface files
Separate compilation allows for reuse of DSLs
Implicit interface may be a limiting factor
DSLs for technical domains are a serious option for a company to
pursue, with demonstrated advantages, but also requiring considerable
effort.
Center for Software Technology Sander Mak