> Code generators are limited to a few common models (patterns). > It leads to bloatware, a multitude of executable objects... implement a > common pattern. The data they interface with may be different, > but the process is the same. You speak as if common interface patterns is a "bad" thing. Easier to train users, easier for new programmers, easy/cheaper TCO (total cost of ownership) We say that about our iSeries all the time, and it should apply to our user software as well. If your generating "bloatware" then you should look at the tool & how you use it, just like we look at our own RPG code. > This seems to be the theory behind the tools I mentioned...: That all > systems can be produced by a limited set of design patterns. Any salesman that says "all" is not to be beleived, and we should know better. > maintenance pgms, use a utility like WRKDBF. Let the programmer do more > creative work. ... with great care to unedited data and it's effects. > the cost of learning these kinds of tools dwarfs the cost of the tool itself. So! Learning RPG dwarfs the cost of the compiler! Taking a week to turn over a complicated screen dwarfs the cost of doing it in a tool in a day (or less). > Also tends to encourage poor use of the tool, which can result in even more > dysfunctional code, and systems. I think it's the programmer, the training, the management that leads to such code. > | The cost of these proprietary languages is relatively high. The > | performance of the executables is relatively poor. Programmer productivity > | is about the same. I've seen otherwise. Tools tend to fit certain type of projects. It requires management as well as programmer committment. As in any IS implementation, poor training, user fear/resistance, inadequate time/budget will kill any project. Jim Franz
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.