|
Let's change the list as well. Could you move it to non-tech? -----Original Message----- From: jt [mailto:jt@ee.net] Sent: Tuesday, December 11, 2001 4:17 PM To: midrange-l@midrange.com Subject: Efficacy of code generators (was RE: Two persons per product") Nathan, I think we're forking from the question of paired-programming (so-called "Extreme Programming") so changed the subject line. See inline... jt | -----Original Message----- | From: midrange-l-admin@midrange.com | [mailto:midrange-l-admin@midrange.com]On Behalf Of Nathan M. Andelin | Sent: Tuesday, December 11, 2001 2:05 PM | To: midrange-l@midrange.com | Subject: Re: Two persons per product" | | | From: "jt" <jt@ee.net> | > IOW, programmers are pricing themselves out of the market, | > IMV. At some point, tools will replace a lot of programmers, | > for this reason. Been going on for a long time now (Synon, Lansa, | > BCD, MRC, etc.) but the process is only gonna be speeded up | > unless programmers achieve greater levels of effectiveness. | | Code generators are limited to a few common models (patterns). | It leads to | bloatware, a multitude of executable objects that do little more than | implement a common pattern. The data they interface with may be | different, | but the process is the same. I agree... | | If a programmer is paid to implement patterns redundantly (like a code | generator), then you're better off using a code generator. I agree, in a sense. If all your coders do is clone the same programs over and over, a code generator will do the job a lot better. This seems to be the theory behind the tools I mentioned...: That all systems can be produced by a limited set of design patterns. I agree with this theory to a limited extent. So I'm not over-sold on the efficacy of code generators. | Better yet, in | my opinion is to use a utility, and avoid the bloatware. For example, | rather than use a code generator to create database inquiry and | maintenance | programs, use a utility like WRKDBF. Let the programmer do more creative | work. Sprout actually ran into a shop that had all their custom apps based on DFU. He proposed replacing these with programs, to avoid all the data problems and operational problems. IIRC, that saw that as too expensive. I would have decided otherwise, myself. I like the idea of using WRKDBF, from a standpoint of avoiding bloatware. But then you've sacrificed the advantages of interactive editing of the data, and are basically returning to running completely batch-oriented processing: Key data, edit data, process data against transaction and master files... | | Some of the tools you mention, of course are more than code generators. | They include their own programming languages, which makes them extensible. This is my primary beef with these tools. As soon as you build in the requirement that you need to learn new languages to implement the tools effectively, that places an additional cost above the cost of the tool. I've never seen any actual figures for the cost of the learning curve. But in my limited experience (with Synon/Obsydian, and just looking over the others), the cost of learning these kinds of tools dwarfs the cost of the tool itself. Also tends to encourage poor use of the tool, which can result in even more dysfunctional code, and systems. I think another question that I'd like to see answered is how well these tools allow you to maintain your existing apps. I know that you can use these tools on your existing database... That's not the same question. (And I don't really believe that most shops have the option of re-gening all their existing apps, using the new tools.) I've been talking to my boss about Synon, and code-generators in general. I'm waiting on additional info, from a second source. I'll just say that code-generators have not, in my experience, been shown to allow shops the option of "having their cake, and eating it too". | The cost of these proprietary languages is relatively high. The | performance | of the executables is relatively poor. Programmer productivity | is about the | same. This is the key question, IMV. I think under ideal circumstances, code-generators will increase programmer productivity by some unknown factor, perhaps an order of magnitude. The question, in my mind, is to what extent these ideal circumstances can be found in TRW. That's an explanation (a looong one ;-) of why I tend to agree with your opinion of today's code-generators/4th gen programming languages (and to an extent OO, though that wasn't mentioned in this thread)... | | Nathan M. Andelin | www.relational-data.com _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l or email: MIDRANGE-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
