I've never used LISP on a big enough project to be sure, but others' experience is certainly like you say. Smalltalk is similar. Both are great. One downside is that you are constrained by the original syntax of the language. Smalltalk is somewhat better than LISP there, since it reads more like natural language. Another downside is the textual format itself: any time you want to refer to something else, you have to do it by typing the same series of characters. It's much more intuitive to use a graphical representation, with a line to the other node. Good modeling tools also let you refer directly to another object, e.g. in UML the data type of an Attribute could be a reference to another Class you have created. The Attribute refers directly to the Class, rather than just copying its name, so if the name is later changed in the Class, the Attribute still points to the right thing (and sees the right name).
Alloy isn't MDA - that's an OMG trademark (and not a very good description: in what way is the architecture model-driven?). It looks like Alloy is a DSL, and it may be that the Alloy Analyzer extends that to a graphical DSM language. If I'm reading right, though, the Analyzer simply shows an analysis of a textual Alloy program in a graphical format - I haven't spotted anything that says you can build the graphical models first.
In any case, your point was presumably that you think Alloy is a good solution for improving the software development process (in some situations). That's great, and there are loads of things like it. None has yet had a major effect on the way the whole community builds software. Certainly a major reason for that is the "cowboy programming" you mention. Most organisations are at that level, but there is a growing number who are moving up the SEI's CMM maturity scale (or even some more realistic measure of maturity).
Most IT systems and game engines are developed from scratch plus copy-paste from old systems, with some 3rd party frameworks and in-house components. For other kinds of systems, like embedded systems, companies tend to have a larger number of programmers working on a larger number of products, but with more similarities between those products, and longer lifespans for these product families. This situation has pushed them to improve their software development processes, making reuse more systematic and paring down the new work needed for each product to a minimum. Those are the industries that are first to reap the benefits of Domain-Specific Modeling.
DSM will do to code what code did to assembler, what assembler did to machine code, and what chips and machine code did to building your own hardware. The industry as a whole will always need the lower levels, and there will still be advances in them, but most developers will be insulated from them and can work at a higher level of abstraction and productivity.
MDA's central failing is that current implementations use UML. As Booch et al. say "the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts." (MDA Manifesto, Grady Booch, Alan Brown, Sridhar Iyengar, Jim Rumbaugh, Bran Selic, MDA Journal, May 2004). In other words, MDA is the OMG's attempt to copy something that has been going strong for over a decade: Domain-Specific Modeling.
Domain-Specific Modeling is about creating modeling languages whose concepts map to your problem domain concepts, rather than everybody's solution domain concepts. UML concepts - at least those from which code is generated - are from the solution domain: classes, attributes, operations. DSM concepts are different for each domain - buttons and icons for digital watches, menus and text message sending for phones, mouse buttons and cacodemons for FPS games. Models are thus at a significantly higher level of abstraction, and independent of any particular implementation technology. They capture just enough (and no more) detail to enable full code generation - and of course the code generators too are domain-specific.
As always, the more specific a tool is for a job, the more productive it can be for that job. It turns out it's best to create a modeling language and generator specific to a single range of products for a single company: the cost of creating the language is more than offset by the higher productivity, providing you're building more than a couple of products. Industrial cases of DSM consistently show productivity increases of 500-1000%. Compare that with MDA, where even vendor-sponsored studies show only 35%.
Whilst it's early days yet for the Microsoft DSL tools, other mature DSM tools exist, both for commercial and research use. I've been involved with one for 13 years, so a) you should suspect me of being biased, and b) I have some small experience of how this stuff actually works in the real world. One key thing is that with a decent DSM tool, building your language, code generator and modeling tool support has to be easy - both at the start and as you evolve the language based on experience. Even our largest customer - with several hundred users and the biggest modeling language we've seen - only has one person assigned part time to that task.
Slashdot Mirror
I've never used LISP on a big enough project to be sure, but others' experience is certainly like you say. Smalltalk is similar. Both are great. One downside is that you are constrained by the original syntax of the language. Smalltalk is somewhat better than LISP there, since it reads more like natural language. Another downside is the textual format itself: any time you want to refer to something else, you have to do it by typing the same series of characters. It's much more intuitive to use a graphical representation, with a line to the other node. Good modeling tools also let you refer directly to another object, e.g. in UML the data type of an Attribute could be a reference to another Class you have created. The Attribute refers directly to the Class, rather than just copying its name, so if the name is later changed in the Class, the Attribute still points to the right thing (and sees the right name).
Alloy isn't MDA - that's an OMG trademark (and not a very good description: in what way is the architecture model-driven?). It looks like Alloy is a DSL, and it may be that the Alloy Analyzer extends that to a graphical DSM language. If I'm reading right, though, the Analyzer simply shows an analysis of a textual Alloy program in a graphical format - I haven't spotted anything that says you can build the graphical models first.
In any case, your point was presumably that you think Alloy is a good solution for improving the software development process (in some situations). That's great, and there are loads of things like it. None has yet had a major effect on the way the whole community builds software. Certainly a major reason for that is the "cowboy programming" you mention. Most organisations are at that level, but there is a growing number who are moving up the SEI's CMM maturity scale (or even some more realistic measure of maturity).
Most IT systems and game engines are developed from scratch plus copy-paste from old systems, with some 3rd party frameworks and in-house components. For other kinds of systems, like embedded systems, companies tend to have a larger number of programmers working on a larger number of products, but with more similarities between those products, and longer lifespans for these product families. This situation has pushed them to improve their software development processes, making reuse more systematic and paring down the new work needed for each product to a minimum. Those are the industries that are first to reap the benefits of Domain-Specific Modeling.
DSM will do to code what code did to assembler, what assembler did to machine code, and what chips and machine code did to building your own hardware. The industry as a whole will always need the lower levels, and there will still be advances in them, but most developers will be insulated from them and can work at a higher level of abstraction and productivity.
MDA's central failing is that current implementations use UML. As Booch et al. say "the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts." (MDA Manifesto, Grady Booch, Alan Brown, Sridhar Iyengar, Jim Rumbaugh, Bran Selic, MDA Journal, May 2004). In other words, MDA is the OMG's attempt to copy something that has been going strong for over a decade: Domain-Specific Modeling.
Domain-Specific Modeling is about creating modeling languages whose concepts map to your problem domain concepts, rather than everybody's solution domain concepts. UML concepts - at least those from which code is generated - are from the solution domain: classes, attributes, operations. DSM concepts are different for each domain - buttons and icons for digital watches, menus and text message sending for phones, mouse buttons and cacodemons for FPS games. Models are thus at a significantly higher level of abstraction, and independent of any particular implementation technology. They capture just enough (and no more) detail to enable full code generation - and of course the code generators too are domain-specific.
As always, the more specific a tool is for a job, the more productive it can be for that job. It turns out it's best to create a modeling language and generator specific to a single range of products for a single company: the cost of creating the language is more than offset by the higher productivity, providing you're building more than a couple of products. Industrial cases of DSM consistently show productivity increases of 500-1000%. Compare that with MDA, where even vendor-sponsored studies show only 35%.
Whilst it's early days yet for the Microsoft DSL tools, other mature DSM tools exist, both for commercial and research use. I've been involved with one for 13 years, so a) you should suspect me of being biased, and b) I have some small experience of how this stuff actually works in the real world. One key thing is that with a decent DSM tool, building your language, code generator and modeling tool support has to be easy - both at the start and as you evolve the language based on experience. Even our largest customer - with several hundred users and the biggest modeling language we've seen - only has one person assigned part time to that task.
Another list is on the VisualWorks Smalltalk Wiki, at http://wiki.cs.uiuc.edu/VisualWorks.
A list of Cincom Smalltalk (i.e. VisualWorks or ObjectStudio) success stories is at http://www.cincom.com/scripts/smalltalk.exe/smallt alkSuccess/index.asp?content=customerProfiles. Unsurprisingly perhaps, that site is running on VisualWorks...