Re: 4GL vs. ESQL/C
Danny Wright wrote: > > I've dealt with pure ESQL/C apps, pure 4GL apps, and hybrid apps. > > My favorite of the 3 was pure ESQL/C - we had a very flexible, easy to maintain > user interface - much better than 4GL forms, and could customize them very > specifically to our own purposes. Pure C? x-) > Pure 4GL apps suffer from not being able to make standard library calls and I > find force people to write shell scripts way too often which are called from > within the 4GL process. This has the disadvantage of splitting control between > a shell script and 4GL source code - who handles the errors? Maybe we should > just die - something pure RDS developers seem all too willing to accept as a > desirable outcome (I want to see details, error codes, line numbers, dates, > times, SQL statements, preferably in a log file so when the user calls me and > says it's broke, I can rely on accurate information rather than some useless, > fatigued, either overly-verbose or overly terse description of some perceived > problem). Perhaps they over did the shell bit in that case. I find a shell interface much easier to integrate than C. ;-) > I;m not sure you can do this in RDS, but don't let the idiots tell you that you > can't use the debugger with C routines in a compiled environment. (I have been > told this where I am currently employed - and currently looking to leave if you > have positions :-)) - it just requires reading the manual or perhaps swiping > source code off of some web site. Do you mean the P-code debugger or a C debugger? > As for the portability of C versus Informix 4GL, you're talking about an NBA > game of the Lakers vs. the Clippers. I have heard too often that there is a > "bug" in SCO-Unix or there is a bug in the Informix port to HP-UX. It happens, > but in some cases it was a case of it just happened to work on AIX (I think > Informix likes that platform for some reason), even though, looking at the > documentation tells you that you're just lucky that it worked on that platform. Blue. > C is infinitely more portable than 4GL... Erm... > In fact, as any idiot knows, compiled > 4GL programs are parsed into ESQL/C programs and finally into plain old C, so if > C is less portable than 4GL, then 4GL is at best only as portable as C....A > paradox? More of an impossibility. But most idiots know that 4GL-RDS is NOT parsed into ESQL/C to start with! You rather give the impression that you have never used RDS. If you do get a chance, then you will find that RDS is an interpretative language and therefore once the interpreter is installed, you just copy your executables over and away you go. I have yet to see someone do that with C code. ;-) > 1 thing about 4GL that really bugs me is that it is not orthogonal. It's American, what do you expect? :-) Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@mydas.freeserve.co.uk |//////// /| | http://www.informix.com http://www.informixhandbook.com |///// / //| | http://www.iiug.org +-----------------------------------+//// / ///| | |This email will self-destruct in |/// / ////| | |10 sec. If you received this email |// / /////| | |in error, sorry about the mess. |/ ////////| +----------------------+-----------------------------------+-----------+
perhaps I was a bit wandering when I wrote that last nite... "Mark D. Stock" wrote: > > Perhaps they over did the shell bit in that case. I find a shell > interface much easier to integrate than C. ;-) > it depends where you're coming from I guess......shell works well, but if you're mixing shell calls with a 4gl program, perhaps to manipulate files, it can make things ugly. If a project is worth doing in 4gl, or C, or even LISP (if you like parentheses), then I shouldn't have to spawn child processes just to accomplish routine things, at least IM(ns)HO. > > > I;m not sure you can do this in RDS, but don't let the idiots tell you that you > > can't use the debugger with C routines in a compiled environment. (I have been > > told this where I am currently employed - and currently looking to leave if you > > have positions :-)) - it just requires reading the manual or perhaps swiping > > source code off of some web site. > > Do you mean the P-code debugger or a C debugger? > Interesting question - I can't even say I'm 100% sure, but I suspect it was p-code because where I did this, there was a good system in place and if I added a C function, I just had to define it in a C source file and a header file and recompile a debugger, which replaced the standard 'fgldb'.....but since global variables usually shared between the C sources and the 4GL sources didn't work, I'd say this was p-code....the only thing which makes me question this is that I never saw any 4go or 4gi files anywhere......The point is, you can still use your friendly 4GL debugger even if your production environment is compiled 4GL. > > As for the portability of C versus Informix 4GL, you're talking about an NBA > > game of the Lakers vs. the Clippers. I have heard too often that there is a > > "bug" in SCO-Unix or there is a bug in the Informix port to HP-UX. It happens, > > but in some cases it was a case of it just happened to work on AIX (I think > > Informix likes that platform for some reason), even though, looking at the > > documentation tells you that you're just lucky that it worked on that platform. > > Blue. > > > C is infinitely more portable than 4GL... > > Erm... > > > In fact, as any idiot knows, compiled > > 4GL programs are parsed into ESQL/C programs and finally into plain old C, so if > > C is less portable than 4GL, then 4GL is at best only as portable as C....A > > paradox? More of an impossibility. > > But most idiots know that 4GL-RDS is NOT parsed into ESQL/C to start > with! You rather give the impression that you have never used RDS. > Hmm, maybe that's why I said "compiled 4GL programs".....can you read? You are right that I haven't used RDS as much as compiled versions, but I see no advantage to it. The compiled version is faster, you can still run it thru your friendly and familiar 4GL debugger, and I have a command line and can use make files instead of relying on the syspgm4gl database. I find makefiles and compiled, archived libraries much easier to deal with than having to setup a new program thru r4gl. > > If you do get a chance, then you will find that RDS is an interpretative > language and therefore once the interpreter is installed, you just copy > your executables over and away you go. I have yet to see someone do that > with C code. ;-) > You mean it's such a hassle to type "make"? I'd much prefer to simply type that, than to have to copy over vast amounts of bloated executables (of course, bandwidth is cheap enough these days, who cares? right?) Of course, if I can compile all my source in a few hours and know that it has all the latest and greatest system patches, who's better off? > > 1 thing about 4GL that really bugs me is that it is not orthogonal. > > It's American, what do you expect? :-) > Hmmm.......C......developed at AT&T.......Isn't that an American company? Are you a Brit or something? > > Cheers, > -- > Mark. > > +----------------------------------------------------------+-----------+ > | Mark D. Stock mailto:mdstock@mydas.freeserve.co.uk |//////// /| > | http://www.informix.com http://www.informixhandbook.com |///// / //| > | http://www.iiug.org +-----------------------------------+//// / ///| > | |This email will self-destruct in |/// / ////| > | |10 sec. If you received this email |// / /////| > | |in error, sorry about the mess. |/ ////////| > +----------------------+-----------------------------------+-----------+
Danny Wright wrote: > it depends where you're coming from I guess......shell works well, but if you're mixing > shell calls with a 4gl program, perhaps to manipulate files, it can make things ugly. > If a project is worth doing in 4gl, or C, or even LISP (if you like parentheses), then I > shouldn't have to spawn child processes just to accomplish routine things, at least > IM(ns)HO. I agree. Look how long it took Informix to get simple ascii file access routines into 4GL. Had to use custom libraries linked in until they finally did it themselves. > Hmm, maybe that's why I said "compiled 4GL programs".....can you read? > > You are right that I haven't used RDS as much as compiled versions, but I see no > advantage to it. The compiled version is faster, you can still run it thru your > friendly and familiar 4GL debugger, and I have a command line and can use make files > instead of relying on the syspgm4gl database. > > I find makefiles and compiled, archived libraries much easier to deal with than having > to setup a new program thru r4gl. My general rule lately has been to use C in batch programs for speed and in cases where you need performance or control. I wrote a radio-frequency scanner program in C so that I could access the curses libraries directly and optimize the text going over the radio link. 4GL sent a lot of hidden codes to control the screen and this made it slow. Batch programs in C typically run 3-4 times faster than their 4GL counterparts. > You mean it's such a hassle to type "make"? I'd much prefer to simply type that, than > to have to copy over vast amounts of bloated executables (of course, bandwidth is cheap > enough these days, who cares? right?) Of course, if I can compile all my source in a > few hours and know that it has all the latest and greatest system patches, who's better > off? Makes it easy to use SCCS too. :-) James Ferrill
Danny Wright wrote: [SNIP] > Interesting question - I can't even say I'm 100% sure, but I suspect it was p-code > because where I did this, there was a good system in place and if I added a C > function, I just had to define it in a C source file and a header file and recompile a > debugger, which replaced the standard 'fgldb'.....but since global variables usually > shared between the C sources and the 4GL sources didn't work, I'd say this was > p-code....the only thing which makes me question this is that I never saw any 4go or > 4gi files anywhere......The point is, you can still use your friendly 4GL debugger > even if your production environment is compiled 4GL. [SNIP] Umm, actually the 4GL Debugger works ONLY with the RDS, or R4GL, ie interpreted version of 4GL. If you code using C4GL, then you MUST use the standard system "C" debugger, preferably a source level one, and debug the precompiled ESQL/C or even the C code. Not that I mind, mind you, but them's the facts folk. Art S. Kagel