Re: 4GL vs. ESQL/C

From: Danny Wright <dw420@airmail.net> > >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. "Easy to maintain user interface"? This must be a meaning of "easy to maintain" of which I was not previously aware. So what you're saying is that it's easier to maintain curses programs than 4GL forms? >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 Uh. I must be writing different type of apps from you. Anyway, you *can* access the standard libraries, even if the method appears arcane. >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). > >Probably the simplest answer, if 4GL development resources are really that >much >cheaper that C resources, would be to call C library routines from 4GL when >4GL's limitations rear their ugly heads (and there are many). Oooh! Get her! >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. In what way? >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 For the 1% of us who don't know what a "laker" is and how it relates to sailing ships, could you please clarify? >"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. > >C is infinitely more portable than 4GL...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. Uh, RDS doesn't compile to C. And it doesn't need recompiling when you move platforms, so it's not dependent on the vagaries of the underlying C compilers. So it's more portable, as portable as or less portable than C. Depending on a set of circumstances. >1 thing about 4GL that really bugs me is that it is not orthogonal. Gesundheit! One thing that really bugs me about ESQL/C is that it's not yohimbine. :0) ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

> "Easy to maintain user interface"? This must be a meaning of "easy to > maintain" of which I was not previously aware. So what you're saying is that > it's easier to maintain curses programs than 4GL forms? > You see, what you do is design good software where you have reliable library functions to call, so you're not messing with curses everyday. You say you want a field to be treated as a certain type and to call (or not call) a particular function before and after entering the field. You also have total control of everything, so it's sort of like an input statement and a form, but instead you have even more control than an input since you can do more than what Informix decided to implement in 4GL (of course you can also shoot yourself in the foot - oh, 4GL doesn't prevent that either, does it?). But a detail, I think I left out, was that this was pretty much a public domain interface (called open-source now, I think) which was published in the late '80s and adopted and customized to suit our purposes. So, basically we implemented most of the good parts of 4GL into an easy to understand, very portable, and completely customizable package. The only advantage I see of 4GL over this is cheap labor - hire an accountant to do your programming - sure, they can compile a 4GL program, but this is where the 47 work days per year statistic comes from (IT professionals only have 47 productive work days per year - Computerworld ('97 or '98 - look it up if you doubt me)) > > >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 > > Uh. I must be writing different type of apps from you. Anyway, you *can* > access the standard libraries, even if the method appears arcane. > By "pure" 4GL app, I meant one that did not access standard C library routines, since doing so would require knowledge beyond 4GL. > > >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). > > > >Probably the simplest answer, if 4GL development resources are really that > >much > >cheaper that C resources, would be to call C library routines from 4GL when > >4GL's limitations rear their ugly heads (and there are many). > > Oooh! Get her! > > >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. > > In what way? > Ok, since RDS uses p-code, I'm not sure you can link it to C libraries. You can certainly use the same nice 4GL debugger with C routines linked - just don't use globals between C & 4GL in this case, and don't expect to be able to step thru C code. > > >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 > > For the 1% of us who don't know what a "laker" is and how it relates to > sailing ships, could you please clarify? > You're really living up to your name, Obnoxio! > > >"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. > > > >C is infinitely more portable than 4GL...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. > > Uh, RDS doesn't compile to C. And it doesn't need recompiling when you move > platforms, so it's not dependent on the vagaries of the underlying C > compilers. So it's more portable, as portable as or less portable than C. > Depending on a set of circumstances. > Well, my point was that your source code, not the p-code or the compiled C code should be portable. Maybe Informix does offer a 4GL interpreter or compiler for every system it offers ESQL/C for, but r4gl and other 4gl tools are probably written in C and thus your arguments about "vagaries of the underlying C compilers" is rendered impotent. > > >1 thing about 4GL that really bugs me is that it is not orthogonal. > > Gesundheit! One thing that really bugs me about ESQL/C is that it's not > yohimbine. :0) > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com