Peter Maas wrote: > If you design a moderately complex UI a designer will be faster. It's > not the speed of typing vs. dragging that matters. You see the result > instantly and don't have to start your program, look, type code, start > again and so on. A GUI builder is more pleasant to work with, at least > with a good one like Delphi or Qt designer.
I haven't worked terribly much with GUI design, but I've written a few GUI programs using both approaches, and I've used Rational Rose to generate C++ code from object models quite a lot. It's my impression that code generation leads to more duplication and less code reuse. It's easy to whip up a new class or window that duplicates a lot of already existing code, with those graphical tools. These tools encourage a development style similar to the copy-paste programming style, and that leads to a big maintenance burden in a longer perspective. Refactoring gets harder, and maintenance suffers if the original information concerning the software is split between source code and other repositories that are used for the generation of programming code. It's also my impression that these code generating tools don't scale so well. When projects get bigger, tools that potentially influence many source files, sometimes causing unnecessary changes due to the way they are implemented, will create havoc in the configuration management systems. There will be blocking locks or conflicts that needs to be sorted out, making it hard for programmers to work in parallel on the same components, and more difficult to track relevant changes between versions in the software. This makes it even harder than otherwise to increase development speed by adding more people to a project etc. Besides the fact that it's quick to generare yet another bunch of files, these tools typically impose constrains that makes it more difficult to use otherwise clever design approaches that would lead to an effective implementation. This has bitten me both with GUI designers and when I used Rational Rose and Plugins for that. For instance there were features in some APIs that were difficult to employ because they weren't supported by our code generation plugin for Rose. I also found that it's easy in Python to make fairly thin GUIs with test stubs that can be fired up and tested quickly during development. If you e.g. have several similar Windows, it's easy with properly written OO Python code to write a main module that supports all the shared features, and a tiny module for each variant of the Window that subclasses the main module. With the GUI designers I used, the typical approach would not involve that kind of code sharing. -- http://mail.python.org/mailman/listinfo/python-list