Just a few clarifications, and I’ll stop taking space on yor blog, I promise

Charles Simonyi is my “neighbour” (Vancouver, BC are my coordinates) so that must be the influence

“While it’s true that static languages don’t have analogous capabilities, however, I fail to see why similar productivity gains couldn’t be achieved with adequate frameworks, IDEs and tools..time will tell I guess.”

I too agree with that, sorry for not being clearer. Statically typed languages such as C# and Java are perhaps not that flexible as dynamically typed and scripted languages, but I’m not sure that this is the reason to take different direction then Lisp, Smalltalk or Ruby. See to put MDA tool, Visual DSL , DSM in the same sentence with any fo those is a joke in a sense
DSL in Ruby is written in Ruby (say Rails), Lisp macros can redefine the Lisp, and Smalltalk is similar.

This is why I’m examining / suggesting just-in-time code generation as the alternative. Think about it as IDE refactoring on strong-strong steroids.

Then to define the DSL for C# application one uses C#, and similar for Java. And this is my basic point. I believe that this solution is then sound, elegant, concise, minimal and universal and that the external tools (MDA, Visual DSM etc) are suggestive and actually very messy. They create this divide and disconnect between the model and the code. I’d rather see the language grow with metaprogramming capabilities instead of extracting that into some external model.

Then the language becomes an universal DSL tool that can tackle your beautiful statement :

“which happens if the degree of variation in a product family is not completely known”.

Saluti,
Emil

RoR does a lot for you behind the scenes and you are right, it is reasonable to give a lot of credit to its reflective metasystem based on Ruby.
While it’s true that static languages don’t have analogous capabilities, however, I fail to see why similar productivity gains couldn’t be achieved with adequate frameworks, IDEs and tools..time will tell I guess.

I must confess that I haven’t really thought about just-in-time code generation about until now (duh!); if I understand correctly, you refer to Ruby’s capability to dynamically extend existing types, which in this context allows RoR to generate code and let users consume it on the fly without additional steps. Is it a better experience than requiring manual steps to the user? You bet !

Are visual languages better than text based languages? I think this question deserves a whole series of posts (well…one at least)!
Let me clarify that, although I keep my eyes open, I don’t buy into the idea that 100% visual modeling and code generation is feasible nor desirable in any but few ad-hoc scenarios. There are big differences between OMG’s MDA (which is totally model-centric, uses UML as input, prescribes PIM and PSM transformations), Metacase’s DSM (totally model-centric, visual DSL as input, claims – and I’m sure obtains – 100% code generation for rather specific scenarios) and Microsoft’s Software Factories/DSL Tools (visual modeling can’t do everything, so graphical DSLs must coexists with code, IMHO applicable in wider scenarios). Effectively, I’m skeptical about MDA, understand Metacase’s DSM (but my domain doesn’t fit in the “applicable” scenarios), but I choose to buy into the latter approach with all its promises and consequences.

In short, I believe that different domains need different languages/notations, some of them should graphical and some should be text-based. Why and when one should be used is an interesting question that I asked myself many times. I must confess I don’t have many answers although I promise I will write something about it in the future.
Hopefully one day the context-switch problem that you mention will disappear if either IntelliJ or Intentional Software succeed in their…intent. As it happens, last February I had the privilege to meet Charles Simonyi and I’ve seen what he is up to…so stay tuned!

I agree that conventions and patterns are key in Ruby on Rails, but the fundamental mechanisms that allow it is RoR metasystem written in Ruby. Sort of like Lisp written in Lisp.

I too think that the ‘Code that writes Code’ is a Good Thing’
but I’m thinking that the codegen (and other artifacts that are generated) unversally work when done just-in-time. By that I mean :-

- ‘universally’ means exactly what you have so nicely explained “that the codegen does not know the degree of variation in a target product or product family”).

- no external model. As much as possible, all the the necessary
descriptions are maintained in the code. The editor, IDE or script,
is automating the step that a developer wishes to perform on the
fly instead in advance.
Everything can be refactored when needed, there is no ‘special’
non-editable and editable classes. Everything is open field.

I looked at the product you mentioned, and I always wander with similar tools why do they think that visual diagrams are better? There is no evidence nor research done in IT industry and Comp-Sci that shows that the visual diagrams are better then text.
It is the opposite that can be argued actually There is often
an issue about ther precision, subtly different interpretations etc..

Few links, that you may find interesting:

Alan Kay on the metasystem topic:
http://www.windley.com/archives/2006/02/alan_kay_is_com.shtml

Intellij Meta Programming System

http://www.onboard.jetbrains.com/is1/articles/04/10/lop/

Saluti,
Emil

I’ve been looking at varius forms of MDD lately, including MDA and DSM (there is a LOT to learn from the experience of the guys in MetaCase since their MetaEdit+ looks like a really mature tool, by the way).

Ruby on Rails is extremely interesting for sure and I can see the advantages of keeping the same language at all levels…
However, the key of its success is perhaps in the conventions (names, patterns, etc) it uses.
Although InnerWorkings is a pure .NET shop, Ruby is often a subject for interesting conversations with my collegues and our experience with Rails has been really positive so far.
In fact, we heavily depend on a custom workflow application that a collegue (and friend) of mine, Michael O’Brien, developed in Rails a while ago.
It coordinates and tracks all the steps across teams in our development process!

- Context (mental) switches from one tool to another is difficult. Using MDD tool, then generating code, and then using a different tool (an IDE for concrete implementation) makes

- Refactoring. The generated code is more difficult to refactor. Sure the templates can change, but then the concrete implementations
may go out of synch, and all the side-effects may not be immediately visible.

One example of DSL that I really enjoy is Ruby on Rails. Sure it is a different and dynamically typed language, but there are very important points there :
The framework, DSL and the scaffolding is in Ruby. There is no difference when editing / using DSL and editing regular business logic. It’s all in the same language, in the same classes in the same editor. The DSL instruction result in code generation on the fly, and programmers barely notice it. People use it without really understanding that this is a DSL. For a developer that is simply Ruby.

Saluti,
Emil

Conheço pelo menos 2 casos de empresas nacionais em que se faz geração de código em larga escala, mas ambos são para domínios muito específicos (nomeadamente, ERP’s), mas quando os domínios são mais latos parece-me mais complicado…

Encontrei um post sobre este tema que me pareceu interessante, e que descreve algumas das dificuldades do MDD em geral…