Now Martin Fowler is coining the Term "Illustrative Programming" in the context of Language Workbenches like IntentionalSoftware, which are tools to build "illustrative DSLs".
For a lot of people coming from the UML camp, the notion of a "DSL" is what Fowler is calling an "illustrative DSL" here. Visual Studio Domain-Specific Language Tools are a striking example of this.
In his article Martin Fowler quotes some opinions of Neal Ford about the concepts of Illustrative Programming:
I think these tools work best for lay people (thus, your link to LayProgrammers). However, in general, tools like this slow down experienced/power users. [...] I would much prefer a markup language I could use to directly define stuff, with macros, snippets, and all the other things I'm accustomed to as a developer. As these tools grow, they get unwieldy (perhaps because they are ceasing to be domain specific enough?). [...] APIs in programming languages scale much better, with several orders of magnitude more density before they become hard to navigate. All the best-practices and tools don't exist there: refactoring, levels of testing, etc. Also, you loose the connection to text, meaning that macro facilities either don't exist or complex one-offs. [...] I share your bullishness around these types of tools, but they are a long time from being useful for full-bore Agile development. I hope they mature fast.
Reading these comments, I am having a deja-vu!
This is really expressing what I was feeling when I was involved in MDSD attempts in recent projects. I don't generally doubt the noble goals that the visual modeling camp believe in.
But the tools and environment are just not ready to provide value. At least not in that kind of mainstream real world enterprise projects I have been involved in.
Also in my experience, the target of illustrative programming is the developers, which is wrong!
As Fowler is pointing out, the goal of illustrative programming is to engage lay-programmers.
Developers need other tools than lay-programmers! So if there are no lay-programmers in your project, there is arguably need for illustrative programming...
This insight was always lacking when I was confronted with attempts at visual modeling.
It is a common mistake in a lot of projects to establish some kind of two-class society among the developers, in this case it could be tempting to degrade the second class to lay-programmers. But that is a sick environment to begin with (and the topic for another post)...
of cource you should follow me on twitter
My feeling is that if the illustration language provides intrinsic value to the customer (which is the case if you have lay programmers in your team), creating an illustrative programming environment can pay off. The price you have to pay is what you would probably call additional 'accidental complexity'.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteI just commented the article about visual modelling:
ReplyDeletehttp://feedproxy.google.com/~r/closed-loop/~3/GI_IXv99jBI/illustrative-programming-i-am-skeptic.html
I must say, when following the four comments of Neal Ford, you can't be but a skeptic of illustrative programming.
However, Ford's comments are just wrong. First, DSLs are understandable and readable by domain experts, instead of IT people (this is one of the original goals of DSM - unfortunately in contrast to what your experience is).
Second, I am actually horrified to read that models of DSLs get unwieldy. The very goal of DSLs is to provide the ability to deal with the complexity of a system, while minimizing accidental complexity (which is in sheer contrast to what bertolami says). Different concerns are expressed with different DSLs (concept of multi-formalism). On top of this, models are expressed in different levels of abstraction (multi-abstraction). The concepts of multi-formalism and multi-abstraction form "multi-paradigm modelling", which explicitly addresses and solves the problem of complexity. An overview of multi-paradigm modelling can be found in the following paper.
http://www.cs.mcgill.ca/~hv/publications/02.AIS.campam.pdf
Section 1 is a very useful introduction. From Section 2 on, it gets a bit technical.
Third, Ford remarks that refactoring, testing, connection with code is gone. This is in some extent true. However connection with code is absolutely not true, as models are systematically translated to code, keeping model and code consistent. About testing and refactoring: this is still under research. This is a massive downside for the possible users of DSLs (you), but a massive upside for researchers in the field of DSM (me), as there are many things to research in this area. There is a bright light at the end of this tunnel: DSLs are formally defined (by a meta-model), so this is very convenient to provide support for testing, refactoring, etc. (Some of these things are research in MDSL, our research group.)
About the Fords fourth comment: I hope my post on visual modelling (cfr. AToM^3) and these comments convince you of the fact that DSM allows extreme agile programming!
Again, I hope I provided some fresh new insights!
Cheers,
Bart
- reposted as I wanted the follow-up to be emailed to me :)
I think you've misunderstood what Fowler means by "Illustrative Programming". It's NOT graphical DSLs or visual modeling. His prime example is Excel, which is neither of those.
ReplyDeleteThe idea of "Illustrative Programming" is that the program runs in the same place that it is defined, and most of what is visible is the results of the program, not the program code itself. That can be achieved both with textual languages (e.g. Excel) and with graphical ones (e.g. UI builders).
Neal Ford's comments are thus not about things he dislikes in MDSD, but things he dislikes in Illustrative Programming tools - essentially End User Programming environments.