Code generation considered harmful

JDeveloper product manager Shay Shmeltzer recently wrote an article titled "Matisse is bad! (and not 'bad' in the good way)" describing what he calls a "disturbing" and "major" problem with the way the NetBeans GUI editor (Matisse) works. He quoted an eWeek review that was generally positive about NetBeans and Matisse but lambasted the editor for hiding the user interface code it generated and for silently deleting any modifications you made in the code with an external editor. In the comments Shay writes:

This visual tool shouldn't then "lock" the code in such a way that prevents you from going and changing the code directly to do little UI tweaks. This is for example what we do in JDeveloper - we give you a visual way to layout your Swing UI (and your JSF/JSP) but you can always also change the code directly.

I think it's unfair to call Matisse "bad" because of the way it handles generated code. Two-way source synching is a very hard problem. For example, the Eclipse Visual Editor makes a valiant attempt at it, but ultimately the whole concept is too fragile for my tastes.

The reason is that source code can be arbitrarily complex. Understanding what the source code is trying to do is practically an AI problem. If the developer refactors the generated code it can completely confuse the reconciler no matter how smart your editor is. So requiring the generated code to not be modified is an inconvenient, but understandable restriction. However, there's a better way.

The real problem with these types of GUI editors is that they generate code at all. Not that Microsoft invented the idea, but Visual Studio, with its various resource editors, has proven that a codeless solution is quite versitile.

That's why I think the ultimate GUI editor would keep the UI description in some form other than code, such as XML. The only reason I suggest XML is that it's self-describing and easy to translate from one form to another. This helps prevent the vendor lock-in that Shay warns about.

There have been various attempts at this (XAML, XUL, XSWT, XForms, etc.) but nothing has really caught on universally yet. Some are too closely tied to their underlying vendor widget classes, and others are needlessly complex. Something open, free, simple, and generic is the way to go. While I'm not a big fan of premature standardization, perhaps this is one area that is ripe for it.