Free seminar on domain-specific modeling
martijn at metacase.com
Wed Sep 21 11:52:36 CEST 2005
> 1. Any organisation that can talk about "a leap in productivity of
> 400% from Assembler to BASIC" as though nothing occurred in between
> suffers such a total disconnect from computing history that it's hard
> to take other utterances seriously.
I believe the point being made by the organization is that during computing
history the most successful shifts in productivity were achieved by similar
shifts in raising the abstraction level on which developers specify solutions.
According to Capers Jones Software Productivity research Fortran is 4.5 times
more productive than Assembler. Looking at chronology I'd say it is not incorrect
to refer to the advent of compilers as a leap.
> 2. "The last OOPSLA ... put forward Domain-Specific Modeling as a
> solution. Similar statements have been uttered recently by Bill Gates
> and Grady Booch, among others." The fact that a technique is promoted
> at a conference doesn't mean the book about it came down from a
> mountain carried by a prophet.
Absolutely. Fact is that both (prophets?) as well as a growing number of
experts (other prophets?) see this approach as a viable one, hence the increased
interest at a growing number of events.
> 3. "Domain-Specific Modeling is only possible because it narrows down
> the design space or domain" presumably means that component-based
> approaches are more successful when the components are created with
> the problem domain in mind. What a surprise.
Nope, it means that instead of using generic languages (programming or modeling)
to specify solutions on top of your platform/component framework, in many
cases it makes more sense to use a language that better fits your problem
Using components is one way of raising abstraction from the "bottom up" and
narrowing your design space. Why stop there?
Depending on how the language has been created, a good DSM language is on
a higher abstraction level than for example C, Java, Python etc. Still, from
model instances you can generate all the lower level code (which in turn
interfaces with your component framework). Wouldn't you agree this makes
development faster and more mature?
> You might also like to look up "flowchart" in your dictionary ;-)
Maybe I will!
More information about the Python-list