Nathan, You put me in a bad way here, because I've been gently chided (someone other than david) for putting too much non-tech stuff on this list. The coin-flip, today, came up "reply on same list as original post". (See inline.) jt | -----Original Message----- | From: email@example.com | [mailto:firstname.lastname@example.org]On Behalf Of Nathan M. Andelin | Sent: Tuesday, December 11, 2001 9:52 PM | To: email@example.com | Subject: Re: Efficacy of code generators | | | From: "Jim Franz" <firstname.lastname@example.org> | > 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)... | | Good point. Patterns are a good thing. The question is when to | use a code | generator, when to use a utility, and when to write your own program? | | A pattern, when implemented as a utility, may be better than | generating new | code. For example, the IBM middleware that generates the 5250 stream is a | utility. It transforms predefined structures directly into the user | interface stream. In contrast, Webfacing uses the same structures to | generate new code (Servlets, JSPs, and Java Beans), which in turn generate | the user interface stream. No additional function (as far as I can tell), | just a lot more code to manage, maintain, and run. This is my contention, also. | | Code generators have a place. However, my opinion is that they are often | promoted and used for purposes that would be better handled by utilities | and/or custom written code. I tend to agree with you again. But I think it's primarily an interface problem. Meaning: a compiler is, in essence, a code-generator. The interface to the compiler (the language) defines your ability to implement functions without knowing the underlying details AND the degree to which you can optimize performance. I think most compilers to a great job of reaching a balance between these contrary objectives. IMHO, most code-generators don't. (I have similar beef with OO.) The emphasis is so skewed towards insulating the programmer from underlying details, that the result is bloatware... Even more, in the process, an added layer of abstraction is introduced. Now many will say that's precisely what's needed to gain programming efficiency. You need an added layer of abstraction to model business processes. My experience has been the opposite.. that coding in ANY language is already sufficiently abstracted from the reality of business processes. IMV, that's why you end up with so much code that doesn't parallel what the business does, very closely... (Actually, this paragraph doesn't reflect my views very well, and this would be another loooong thread, in itself.) I asked the question whether today's code generators have progressed much, in this regard, since I looked at them in detail a few years ago. Whether other code-generators are vastly superior to Synon/Obsidian and the one JDE used to generate their green-screen apps. Maybe they have... Maybe not. Either way.. doesn't mean they couldn't do MUCH better. | | Nathan M. Andelin | www.relational-data.com
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.