Free seminar on domain-specific modeling
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Free seminar on domain-specific modeling
> Martijn Iseger wrote: > >> 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! > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Free seminar on domain-specific modeling
> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Free seminar on domain-specific modeling
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Free seminar on domain-specific modeling
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 -- http://mail.python.org/mailman/listinfo/python-list
