Re: 4gl: Better than sliced bread?

->From: bill@promdist.pds.com (Bill Foote) ->Subject: 4gl: Better than sliced bread? ->Date: Wed, 12 May 1993 19:27:46 GMT ->Reply-To: bill@promdist.pds.com (Bill Foote) ->Organization: PDS Corp., Los Angeles, CA USA -> ->In article <1993May11.211120.27014@rpslmc.edu> eklhad@siss81.sis.rpslmc.edu (Karl Dahlke) writes: ->>Our first version of the general_view_screen system was ->>extremely awkward, due primarily to the lack of function pointers in 4gl. -> ->I'm having fun in c.d.i today. Is this an example of one of the powerful ->features of 4gl that give you that ten-fold productivity increase? -> ->Hmmm, given the lack of function pointers, the creation of any kind of ->abstract data type would be nigh on impossible. Well, who needs software ->engineering anyway? Real Men (tm) don't write generic functions. Useful ->function libraries? Bah -- who needs 'em? -> ->Seriously, I've never used 4gl, but from what I've heard it's useful for ->knocking out applications that don't get too involved. As long as you ->don't need to do anything that requires the power of C, it's OK, and they ->let you link in C functions when you need to. If you want to write anything ->like a general library that you can re-use, or a program that uses pipes ->or anything slightly complicated, you're better off in C. ----------------------------- Golly, I'm starting to sound like an Informix flack, rather than just a satisfied user. However.... I have written entire, complex applications in 4GL using the SE engine, including a multi-task, multi-window application in which the separate, asynchronous tasks periodically sync'ed thru the database. This applica- tion ran flawlessly (well, the flaws were mine, not Informix 4GL's) thru X-windows over a 2,000 mile network link. The only C function I ever needed was 'i_getenv()', which was written before 'fgl_getenv()' became available. I've written reuseable libraries; at least I reused the same code, in *.o form, in several different projects. Code reuseability is more a function of designer/programmer cleverness than of language power. Remember Fortran? ----------------------------- -> ->In summary: 4gl is less powerful than C, but more convenient for a certain ->class of applications. ----------------------------- That depends on your definition of power. I have seen wood scultors use a chain saw to rough out a sculture, then use chisels, and finally scalpels to do the fine detail work. C is a heck of a fine scalpel, but I would hate to have to do entire wood sculture using ONLY a scalpel. Maybe it is better to have more than one tool available to programmers, each to be used in the appropriate part of the application. ----------------------------- -> ->I'm curious: From the people out there who have used 4gl and C extensively, ->what would you say the "productivity gain" is? My guess is that 4gl is good ->because it's easier to learn than C, and not-too-complex stuff can be done ->quickly and efficiently. As long as there's one good C programmer on staff, ->I'd believe that 4gl could be an effective tool, but I'd hate to be limited ->to it. ----------------------------- 4GL is good for the same reason that C++ is replacing C. Things like strong type checking save even good programmers from silly errors. 4GL has its flaws, but so does C (or porbably any programming language). Things that are complex in one language may be simple in a different language; it depends on how the decisions of the language impelementers coincide with your particular needs. ----------------------------- -> ->Even so, I think that the "ten-fold" increase in productivity is either: -> -> 1) Inflated by a factor of 5 or more. -> 2) Only applicable to people who don't know how to program in C. ----------------------------- I also doubt a *sustained* 10X increase in productivity. It depends on what you are doing in your application. As the car dealers say, "Your mileage may vary." Once you buy into the look-and-feel of what 4GL does easily and well, such features as MENU statements and OPEN WINDOW do indeed produce a high productivity gain, versus doing the same thing from scratch in C. Please see my previous posting regarding MENU. Doing what 4GL does not do well is difficult in 4GL. However, when was the last time you enjoyed using two-dimensional arrays in C? ----------------------------- -> ->So, 4gl/C programmers, am I right? Or should I go out and buy 4gl ->*quick*, before it makes C++ obsolete? :-) -> ->While I'm at it, does 4gl have a symbolic debugger that's anywhere near ->as good as gdb? ----------------------------- The 4GL Rapid Development System (RDS) has an integrated, symbolic, inter- active debugger. Some people swear by it; I swear at it. (But I don't like debuggers in general.) Please note that 'gdb' is not inherent in C, it took the GNU folks to make it. ----------------------------- -> ->(NOTE: This is *not* a flame of Karl Dahlke's posting... It's more an ->expression of amusement at the Informix sales literature. What they're ->saying is almost identical to the sales talk given for Jovial, a language ->that my father helped develop at SDC. In the Jovial article in the SDC ->newsletter, they talk about how "interactive, convenient access to a ->database will allow non-programmers to view data and easily generate ->reports". This was written in 1967. Sound familiar?) ----------------------------- Please, you're making me feel old. I wrote a considerable number of programs in Jovial, including a *generalized* report writer against a database of military engagement (no, not Tailhook!) scenarios. ----------------------------- ->-- ->Bill Foote bill@pds.com ->PDS Corp, Los Angeles, CA USA uunet!promdist!bill -> Regards, Alan +------------------------------+---------------------------------------+ | R. Alan Popiel | Internet: alan@den.mmc.com | | Martin Marietta, LSC | ( Please note: My opinions do not ) | | P.O. Box 179, M/S 5422 | ( represent official Martin policy. ) | | Denver, Colorado 80201-0179 | Voice: 303-977-9998 | +------------------------------+---------------------------------------+