Tuesday, October 3, 2006
Tuesday started with our first introduction into the whole Domain Specific Languages hoop-la. The dream of really being able to write DSLs that domain experts can actually use to codify business rules was alive and well at this track. The funny thing is that, as Dave Thomas pointed out, the only examples you ever see of this sort of thing are for tiny, generic, well-defined domains like finite state machines.
The presentation we saw was “DSLs Best Practices illustrated with Eclipse Tools” by Markus Voelter. It was quite well presented and the speaker obviously knew what he was talking about. Nonetheless, I remained unconvinced of the applicability and the value of the approach: the amount of technical complexity required to get a running system out of one little example was so high it hardly seemed worth it (and in this example, the DSL was modeling a state machine that still required a programmer to fill the business logic that had eluded the DSL into some callback that the generated code would use).
All that said, I don’t really have any experience of my own working with DSLs, so I’m not really qualified to give an opinion on them (except for when I hear the term “meta-meta-model;” then I still feel that I’m entitled to laugh, or at least snicker).
Later in the afternoon, Eric Evans gave a presentation about “Domain Driven Development and DSLs”. I agreed with his opinion that domains are too rich and complex to be captured by a DSL that most people could write. He made the interesting point that most domain experts do not have the skills to specify precise and comprehensive business requirements in a DSL, let alone to write one.
The point is that writing a language is very hard. We all have an intuitive sense of what a language is like, but that’s usually also a naive one; for a computer to do anything with a language, the language has to be very precise and complete. It’s hard enough for people to establish a not-too-vague language for the domain that they wish to model, yet the human use of language is full of ambiguity. Evans did say, however, that he thought that perhaps DSLs could be used for very small, well-defined, generic sub-domains (his example: http://timeandmoney.domainlanguage.com).
Evans gave additional insight into the nature of modeling for business software development which cast further doubt on the usefulness of DSLs. For Evans, there is no single “correct” domain model. One can think of several models for a domain, depending on what exactly it is that we need our application to do. So a model is useful given a certain context and application, and when we are choosing models, we do so with that context in mind. If the context changes, then the model may also have to change. For this reason, a DSL may be problematic in that it implies a particular model for a domain. The question is: how specific is the language and in what contexts does it apply?
We also saw an interesting presentation entitled “Performance Anti-Patterns” by Kirk Pepperdine. The talk emphasized three common anti-patterns:
- shot in the dark (attempting to diagnose the problem by reading the code rather than by empirical measurement)
- no stress testing (testing only the easy path, no systematic randomized testing plan)
- datalite (testing against an unrepresentative dataset)
On our project, we are now approaching performance testing with the amount of rigor presented in this talk (that is, according to the solutions to the anti-patterns, not according to the anti-patterns). I’d like us to look at using Apache JMeter (http://jakarta.apache.org/jmeter)again and seeing if we can write a plug-in for it that will let us test against our SWT interface.
We ended the day doing the JAOO-IT Run: 1 Danish Mile.