Meta-languages and meta-platforms are usually perceived as a complicated solution – Meta-code is a tricky thing. That’s no excuse, however, to make things even more complicated than they should be. The mental cost of thinking in meta-terms is enough: You don’t have to throw other complications in.
UML was never lightweight – A standard that was rolled out with 9 different diagrams sounds more like a committee’s compromise that something usable. When you start using UML meta-programming platforms (“Eclipse Galileo modeling” edition is shipped with a few) you find out just how ridiculously entangled it has become. The excellent Acceleo framework uses 3 different meta-languages (UML, OCL and EMF) to generate Java code that can generate other code from a UML model. Suddenly LISP’s Meta-Object Protocol or Python’s Metaclasses seems like the simple solution. Don’t get me wrong – Acceleo, comparing to other UML-based solution, is a great framework – But enough is enough. It’s difficult enough to write a meta-program in a single language. Two languages are somewhat expected too – A language and a meta-language. Piling 3 or 4 different frameworks into meta-programming is not the right solution – It’s the result of desparately trying to handle an over-complex meta-protocol.
I have some code generation program that I need to implement. Eventually, it will be an Eclipse-based plug-in… But before that, I think I’ll hack it in Python.
(Btw, there are alternatives to UML: OPM and Planguage to name a few. More to come on this)
2 comments so far, add yours ▶