Lambda the Ultimate

inactiveTopic UML and DSLs
started 4/22/2004; 3:40:54 AM - last post 4/26/2004; 3:03:10 AM
Ehud Lamm - UML and DSLs  blueArrow
4/22/2004; 3:40:54 AM (reads: 8753, responses: 6)
UML and DSLs
Forget the Microsoft slant of the referenced blog post, and consider the fundamental issue. Despite the name UML is hardly a language, given the problematic nature of UML semantics (yeah, I know about OCL).

Modelling and specification are just as much in need of well defined semantics as is programming. Perhaps even more.

In order to provide good tool support we need to have a standard syntax, well defined semantics, and rigorous domain models.

Language designers are here to stay... The PL community is likely to produce the next innovation in software engineering.

But that doesn't surprise anyone here, does it?

Posted to DSL by Ehud Lamm on 4/22/04; 3:41:28 AM

Andris Birkmanis - Re: UML and DSLs  blueArrow
4/23/2004; 10:31:21 AM (reads: 254, responses: 0)
LtU could sponsor a survey: 1. whether people use UML for decorating napkins, and 2. whether they generate code from UML.

I personally do 1. quite often, and regard this just as a variety of mind mapping. I do not do 2. at all, though the company I work for does it on a regular basis.

I do generate a lot of UI and state management code from models, but that does count as DSL, right? ;-)

Chris Rathman - Re: UML and DSLs  blueArrow
4/23/2004; 7:09:28 PM (reads: 230, responses: 0)
If you believe the hype, we programmers are a dying breed. :-)

Frederik De Vos - Re: UML and DSLs  blueArrow
4/24/2004; 7:19:06 AM (reads: 207, responses: 0)
Until I see a complex application of real executable UML, I'll be very skeptical about MDA. The UML diagrams would be likely to cover a soccer field. UML was originally aimed at communicating overall structure. How could it ever be turned into something executable, without becoming a huge web of constraints, associations, generalizations etc...? If the goal is to make things more simple and more efficient I have strong doubts MDA does that.

Wouldn't logical/functional programming languages do a better job at grasping the functional requirements? My intuition tells me that less code is refreshing and that imperative languages imply more choices that could later prove to be a problem. Smarter IDEs and refactoring won't wash that away.

Andris Birkmanis - Re: UML and DSLs  blueArrow
4/25/2004; 4:18:32 AM (reads: 189, responses: 0)
Computer scientists ... tend to prefer formalisms that are more complicated and less powerful than simple mathematics.

It was said about type systems, but can be applied to MDA. :-)

Sébastien Pierre - Re: UML and DSLs  blueArrow
4/26/2004; 1:49:21 AM (reads: 150, responses: 1)
I'm very curious to see how this MDA hype is going to evolve... I see that all these OMG and corporation-driven initiatives converge to the same goal: allow more people to develop (complex) applications without the knowledge currently required to do it.

Still, even if it was actually possible to compose an application by visually associating components (this is one of MDA aims), I guess that the problem would still rely in managing the complexity inherent to composition (it is usually a pain to make components interact properly together).

Above all, UML 2.0 seems on the wrong path, being based too much on industrial languages (C++, Java), it focuses on modeling data but is poor on modeling behaviour. And behaviour is just the problem of interacting components.

Anybody has tried to use UML for functional languages ?

Also, it is interesting to read Martin Fowler's opinion on MDA,

Andris Birkmanis - Re: UML and DSLs  blueArrow
4/26/2004; 3:03:10 AM (reads: 146, responses: 0)
the problem would still rely in managing the complexity inherent to composition

While I am in Lamport-mode, a citation to back your statement: Composition: A Way to Make Proofs Harder

A controversial paper (IMHO, of course), but I like to read controversial papers :-)

[On Edit: oh, I already cited this on the thread, looks like my mind has been affected by reading too much this weekend. Sorry :-(]