Comment Re:LISP promises, Domain-Specific Modeling deliver (Score 2, Insightful) 62
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.
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.
