Code generation considered harmful

Code generation considered harmful

Summary: Matisse, the NetBeans GUI editor, was recently described as "bad" because of restrictions on editing the Java source it generates. This is unfair, however, because the whole idea of generating code is fraught with danger.

SHARE:

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. 

Topic: Software Development

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • Tweak any generated ASM lately?

    I really don't get the attitude of people who insist that generated code must be "tweakable".

    Think about a C++ compiler (sorry to bring that up) that generates ASM code. Yes, it's "code", but how many people edit it?

    I think the "trick" here is to get people to realize that generated Java code from a visual builder is no different than generated ASM code from a C++ compiler. Neither should be expected to be tweakable.

    Of course this means that visual builders must have the appropriate ways to hook in "extra" behavior. (That's where mine was going). Something like a combo of template method with strategies that can be plugged in where requested, but the strategy calls don't exist unless you've used a hook in the builder.

    Of course a very simple solution would be to
    * generate Java code
    * compile it to bytecode
    * delete the java code

    Making it obvious that there is no intent of letting you edit.

    I hate "round-tripping" for the reasons you state, and my visual builder wasn't going to support it.

    Code generation is your friend, but it should be a one-way process.
    - Scott
    javadude_z
    • Re: Tweak any generated ASM lately?

      Output assembler code isn't generally meant to be read by a human (well, I've read a lot of it but you know what I mean). I think that's different than a tool that inserts code in the middle of your own code.

      The main argument for code generation is efficiency. There are some cases where that would matter (bulk transfer and conversion of megabytes of data for example) but for user interfaces a little interpreting is not going to be noticable.
      Ed Burnette
      • Re: Tweak any generated ASM lately?

        ASM is source. It's inserted into your code base...

        It's all attitude, which is why I suggest just outputting bytecode instead of leaving the java source sitting around for people to whine about how their edits get eaten ;)
        javadude_z
    • Avoid GUI builder altogether

      I guess the trick is, I've seldom seen a GUI builder that was half as good as a C++ compiler.

      If indeed they are going to trash the modifications that a person makes, then the tool should lock the developer out completely so that they don't waste time and effort on fixing bugs in the GUI. Better to avoid the GUI builder altogether.
      __howard__