Free seminar on domain-specific modeling

[Martijn Iseger]

Domain-specific modeling makes software development 5-10 times faster than
approaches based on UML or MDA.
It accelerates development and reduces complexity by automatically generating
full code from higher-abstraction design models.
Learn from speakers Juha-Pekka Tolvanen, Jack Greenfield, Steven Kelly and
Krzysztof Czarnecki about DSM and how to implement it.

Time: Friday, October 21, 2005. 8:00am - 12:00noon. Right after OOPSLA.
Place: Town & Country Resort & Convention Center, San Diego.

More info and registration: http://www.metacase.com/DSMseminar

 

[Gerrit Holl]

Domain-specific modeling makes software development 5-10 times faster than
approaches based on UML or MDA.
It accelerates development and reduces complexity by automatically generating
full code from higher-abstraction design models.
Learn from speakers Juha-Pekka Tolvanen, Jack Greenfield, Steven Kelly and
Krzysztof Czarnecki about DSM and how to implement it.

Time: Friday, October 21, 2005. 8:00am - 12:00noon. Right after OOPSLA.
Place: Town & Country Resort & Convention Center, San Diego.

Will the trip there be free as well?

Gerrit.

(sorry, couldn't resist)

 

[Peter Hansen]

Domain-specific modeling makes software development 5-10 times faster
than approaches based on UML or MDA. It accelerates development and
reduces complexity by automatically generating full code from
higher-abstraction design models.

Wow, look everyone! A silver bullet!

 

[Martijn Iseger]

Wow, look everyone! A silver bullet!

Before slashing down in ignorance - educate yourself on www.dsmforum.org.
After that: feel free to comment. I will make you look a lot more intelligent
Peter Hansen.

 

[Fredrik Lundh]

Before slashing down in ignorance - educate yourself on www.dsmforum.org.
After that: feel free to comment. I will make you look a lot more intelligent
Peter Hansen.

if you don't understand the "silver bullet" reference, you're not qualified to use
phrases like "makes software development 5-10 times faster".

</F>

 

[bryan rasmussen]

I just wonder about that 5-10 times faster. that's a really wide range.

 

[Martijn Iseger]

if you don't understand the "silver bullet" reference, you're not

qualified to use phrases like "makes software development 5-10 times
faster".

You could reverse that as well: http://www.dsmforum.org

 

[Steve Holden]

You could reverse that as well: http://www.dsmforum.org

Having taken the time to educate myself (following the repeated spamming
to promote a seminar) I can offer the following observations, but I am
omitting the URLs as I believe you've already had far more publicity
than the site really merits.

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.

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. The technologies the dsmforum site rubbishes were
similarly promoted. If you *have* to choose a prophet then I'd stick
with Booch, as Gates has proved many times that he's a far better (or
anyway more ruthless) businessman than he is a software architect.

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.

And so on. Please note I am not saying that DSM has nothing to offer,
simply that it isn't marketing itself any more effectively (or IMHO any
more convincingly) than any other comparable technological advance.

Since you appear to be an account or channel manager perhaps the best
advice I can give you is to leave c.l.py to your technical staff and
avoid such blatant self-promotion. DSM might seem like a silver bullet
to you, but others have seen similar claims come and go without major
changes in software methodology.

You might also like to look up "flowchart" in your dictionary ;-)

regards
Steve

 

[Martijn Iseger]

Hello Steve,

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
domain.
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!

Regards,

Martijn

 

[Magnus Lycka]

Before slashing down in ignorance - educate yourself on
www.dsmforum.org. After that: feel free to comment. I will make you look
a lot more intelligent Peter Hansen.

Talk about throwing stones in glass houses!

 

[Steve Holden]

Hello Steve,




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.

Neither would I. I was simply pointing out that BASIC wasn't the next
thing after assembly language. Even before Fortran there were a whole
bunch of what were usually called "autocodes", one of the more popular
ones in Britain at least being EMA (extended Mercury autocode. So it
wasn't really a leap, more a sequence of steps.

I could promote nuclear weapons as being a quantum leap above
rock-throwing (millions of percent more kill efficiency), but I'd be
falsifying the picture by omitting depressing centuries of weapons
development in doing so.

Most BASICs weren't compiled languages anyway: BASIC's primary feature
was the introduction of interactive execution modes and immediate
edit/run cycling. The addition of compilation to machine code is a
relatively recent phenomenon for (only some) BASICs, unlike other
high-level languages.

regards
Steve

 

[Michael Sparks]

Martijn Iseger wrote:
....

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.

The alternate point is that during computing history, many, many, many
promises were made for many, many, many, technologies based on the
same principle of raising the abstraction level. Many, many, many of
those technologies promised much and failed to deliver on their claims
when used beyond the people inventing/using those technologies.

Furthermore, virtually all of them get marketed as being the next big
thing that Will Change The World. As a result anyone marketing an idea
in this way meets skepticism. From my perspective your site talks a lot
about general ideas but has little on specifics.

One thing is relatively clear - your approach appears to include a
graphical approach to systems building. Personally I suspect that the
fact people are able to engage other parts of their brain when building
these systems beyond linguistic is the real reason you see benefits,
rather than actually the specific thing that led to the visual approach
being possible.

Maybe your approach will change the world. Maybe it won't. If it's
better and it does, good. If it's not better and it does, that's a lot
of effort for no gain. Unfortunately that latter point is a common
result.

(On a sad note it looks like you're reinvented how hardware is designed
and made, but not made the intuitive leap :-/ )

Best Regards,


Michael.

 

[Martijn Iseger]

Hello Michael,

The alternate point is that during computing history, many, many, many
promises were made for many, many, many, technologies based on the
same principle of raising the abstraction level. Many, many, many of
those technologies promised much and failed to deliver on their claims
when used beyond the people inventing/using those technologies.

True, DSM however is not so much a new method for develping software. It's
been used since the early 1990ies as far as I know and seen many sccessful
implementations of it in varying sectors of industry: From mobile phones
(Nokia uses it to develop the software running in all their phones) to IP
switching platforms (Lucent), CRM systems, pacemakers, home automation systems,
J2EE-based B2B portals (insurance industry), car infotainment systems (Audi
A6), messaging systems (USAF), enterprise apps on smartphones (Nokia series60),
Tooling industry and many more. Success with DSM depends on several factors
like a common platform used for developing applications or variants of applications
and the presence of domain-expertise: That leaves out one-time projects.

One thing is relatively clear - your approach appears to include a
graphical approach to systems building. Personally I suspect that the
fact people are able to engage other parts of their brain when
building these systems beyond linguistic is the real reason you see
benefits, rather than actually the specific thing that led to the
visual approach being possible.

It is actually based on the graphical approach. The important thing I see
here is that specific instances of this approach are defined by a company's
expert developer instead of by a standards-body or a vendor, this puts the
expert in the driver-seat so to say, he/she gets the ability to formalize
(changing) development practices in his/her problem domain for the rest of
the (less experienced) developers to follow automatically. Instead of adopting
a one-size-fits-all approach companies/developers get to tailor the approach
to the specific needs of their unique problem domain. It does not eliminate
coding but attempts to minimize the need for it and leave it to the people
who are really good at it.

(On a sad note it looks like you're reinvented how hardware is
designed and made, but not made the intuitive leap :-/ )

I suppose you mean software here? It seems I fail to make the "leap" towards
understanding what you mean with this, feel free to elaborate.

Regards,

Martijn