This is true only for programming in the small, isn't it?
my favourite opinion on that subject was expressed, back in 1984, in Burstall, Lampson A kernel language for modules and abstract data types http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-1.html paraphrasing: programming-in-the-large should look pretty much like programming-in-the-small. what you need is a simple notation 'for dealing with big objects (pieces of a program) as if they were small ones (numbers); this is the basic good trick in matrix algebra'. meta-mudelling is a popular subject (and my tendency towards puns is not to be construed as a criticism - i like going meta if i can do so without going crazy;-), but the pragmatic focus is on the models, isn't it? try not to think of a modeling language for Haskell code. instead, think of Haskell itself as a meta-modelling language: first, you design a modelling language suitable for the problem at hand, then you make that modelling language precise and executable by prototyping it as an embedded domain-specific language in Haskell, then you model your problem in that modelling language. finally, you run your model. sometimes, you are done at this point. sometimes, you will need many more models, more efficiently implemented, so it makes sense to move from the prototypical implementation of your modelling language to an efficiency-oriented one (perhaps by turning an embedded interpreter into an embedded compiler and runtime system). sometimes, you only needed that one model, but you need it faster, and in a different language, to fit into some external constraints, so you either make your embedded compiler generate code in that language, or you re-implement by hand once you know that your model does what you want. of these, only the last alternative is not in line with model-driven development, in its code-and-model-are-linked-by-tools incarnation. if you need to model parsers, you start with a parser language, if you need to model other grammar-based problems, such as type systems or operational semantics, you generalise to monadic combinators, if you need to model financial contracts, you start with a contract language, if you need to model animation, you start with an animation language, if you need to model graphical representations of data-flow, you start by embedding Petri nets, and so on.. it is up to you to find and define the right modelling language for your problem/ domain/audience/customers/bosses/.., but Haskell provides good abstractions to build on, and -not to be underestimated- a common framework (or meta language) in which several such modelling languages can be combined. the latter not only means that abstractions common to different modelling languages can be extracted into libraries, and studied in general (such as monads and monad transformers), it also means that your model of a grammar can be integrated with your model of an execution mechanism, which in turn can be linked with your visual model of static and dynamic properties of your systems. in other words, you can model complex systems in a single framework, while still getting to choose the most appropriate language for modelling each part of your system.
Hmph, how to disprove this argument? Say, you have generated ddl-code from an ER-model and now want to generate Haskell data structures that operate on this data. How would you procede? This is similar to HaXML that helped you to generate Haskell types for an xml schema.
provided that the modelling language is defined precisely, you can write a compiler for it in Haskell (Haskell is good for writing compilers, remember?-). such a compiler could generate Haskell code, or tools, or data types, or.., or even Java code. rumour has it that it could even be used to reverse engineer and process Cobold, if necessary;-) (the xml example -is that xml schemata or dtds, btw?- demonstrates that precise definitions don't necessarily make for concise code, but thats what you get with standards..) claus which reminds me that so far there have been only two times i found myself agreeing with anything umlish: a paper by Harel explaining his ideas about statecharts, and a workshop of umlers i stumbled into, where it became clear to me that those pragmatic users of uml mainly use the graphics to depict their type hierarchies, while tending to ignore the advanced, complicated, and not necessarily well-defined aspects of uml.