Very Computer

Our first version of the general_view_screen system was
extremely awkward, due primarily to the lack of function pointers in 4gl.
(I will spare you the evolutionary details.)
We conclude that function pointers, or a similar mechanism,
is necessary.  So I wrote one.

The C function tb_fneval(..., funcname)
pops the string funcname and interprets it as the name of a 4gl function.
It scans the symbol table (programs cannot be stripped),
finds the function name, reads the location, and calls that 4gl function,
leaving the remaining arguments on the stack,
as though the call-ing function had invoked the call-ed function directly.
The initial lookup can be slow for large symbol tables
(not much I can do about that),
but subsequent references to that function are instantaneous
because I cache all function name/location pairs.
Thus the name of the function (as a string) is the function pointer.

The system is not perfect.
Symbol tables must be retained, and each program must be able to
(reliably) read itself.
We force all programs to be run with absolute paths,
so tb_fneval knows right where to go for the symbol table.
This affects our users not at all since we put
the absolute path of the application in their .profiles,
but it sometimes annoys us.
When you build a test version of the program foo,
you must invoke it via ./foo.
A small price to pay for function pointers.

Another problem is the (theoretically helpful) compile
time 4gl argument consistency checks.
Call tb_fneval with different numbers of parameters or returns
from the same file, and 4gl generates an error,
even though that is exactly what you want to do.
We have simply broken our code up into smaller files and functions,
so that this never happens.

Most people never use this function directly,
so its compile time drawbacks are not a problem.
Instead, they call the general_view_screen mechanism,
and tell it that, upon f6, it should fetch the current row
and call "whatever_f6()".
The actual tb_fneval calls are buried inside our gvs code.
This function pointer capability is a critical first step towards
a general, flexible screen development system.
--
        I do more all day -- than most people do before 9 A.M.

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.

In summary:  4gl is less powerful than C, but more convenient for a certain
class of applications.

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.

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.

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 de* that's anywhere near
as good as gdb?

(NOTE:  This is *not* a flame of Karl Dahlke's posting...  It's more an
expression of amu*t 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?)
--

PDS Corp, Los Angeles, CA  USA                          uunet!promdist!bill

->Subject: 4gl:  Better than sliced bread?
->Date: Wed, 12 May 1993 19:27:46 GMT

->Organization: PDS Corp., Los Angeles, CA  USA
->

->>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 de* that's anywhere near
->as good as gdb?
-----------------------------
The 4GL Rapid Development System (RDS) has an integrated, symbolic, inter-
active de*.  Some people swear by it; I swear at it.  (But I don't like
de*s 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 amu*t 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.
-----------------------------
->--

->PDS Corp, Los Angeles, CA  USA                     uunet!promdist!bill
->
Regards,
Alan
+------------------------------+---------------------------------------+

| 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                   |
+------------------------------+---------------------------------------+

OK, point taken.  4GL can (probably) do some pretty good stuff (and I only
say "probably" because I've never used it myself).

As someone who uses pointers to functions *a lot*, this comment:

Quote:>->>Our first version of the general_view_screen system was
>->>extremely awkward, due primarily to the lack of function pointers in 4gl.

bothers me.  OK, so most people don't do stuff that really requires
function pointers very often.  (Pilots *rarely* need their parachute,
too, but I'd hate to be without one!  :-)

Quote:>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.  

My only quibble with the above is this:  Does 4GL give you something like
#include files where you can put function prototypes, so you get things
like parameter type checking?  I remeber the Bad Old Days, before ANSI-C,
and I never want to go back!

OK, I have one other quibble.  Would it be possible to write something
like qsort() in Fortran (or, for that matter, in 4GL)?  To do qsort
cleanly, you *need* pointers to functions (or their equivalent).

Quote:> Remember Fortran?

I had blotted it out.  Thanks for reminding me.  :-)

Quote:>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.

 ^^^^^^^^^^^^

That's the key.  No decent C programmer would ever *consider* doing
it from scratch.  He'd either buy a library that does it, or write
it once, and put it in a library.  Then he gets the productivity
gain of having OPEN WINDOW et al., and he doesn't have to suffer through
some of 4GL's shortcomings.

That said, I concede that 4GL could well be a good tool that helps to write
a certain class of applications.  It's also probably easier to use than
C in some senses, and almost surely easier to pick up than C.  But I
still like C better!  (I also think that Forth is kinda neat, so maybe
there's no hope for me :-)
--

PDS Corp, Los Angeles, CA  USA                          uunet!promdist!bill

Well abstract data types are not the only answer to the world's problems.

Quote:> 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.

Well, one of the 4gl programmers who works here has a gigantic library of
code.  I write small interface functions to the library and my applications
can access all kinds of ``re-usable'' code.

Quote:> In summary:  4gl is less powerful than C, but more convenient for a certain
> class of applications.

It is not necessarily less powerful.  It is a different type of tool.  You
wouldn't say that PERL is less powerful than C, or vice-versa.  They were
written for different uses.  You have to use the right tool of the job.

Quote:> I'm curious:  From the people out there who have used 4gl and C extensively,
> what would you say the "productivity gain" is?

Well, as long as you use 4gl for what it was designed for (UI and relational
database access) it is an effective and useful tool that increases
productivity.  When I need C and database access, I use ESQL/C.  When I need
to manipulate data to a great extent, I dump from the database, use perl, and
load it back in.

Quote:> So, 4gl/C programmers, am I right?  Or should I go out and buy 4gl
> *quick*, before it makes C++ obsolete?  :-)

Again, it is a matter of using the right tool for a job.  An OODBMS would be
nice, and there are products out there for that.  But code sharing (what you
were talking about before) and object orientation are not the same thing.
Granted, regular Informix-4gl is not an object oriented, but code sharing is
still possible, just as it is in C.

Quote:> While I'm at it, does 4gl have a symbolic de* that's anywhere near
> as good as gdb?

Not that I know of, but it isn't really needed.  You don't get core dumps
(usually :-) with a 4gl program.  Usually you get a message that tells you
what caused the error and what line it occurred on.  Debugging is a relatively
short proccess in 4gl when compared to C or C++ (at least for me).

4gl's were designed to make a subset of applications programming easier.  I
think that they have done that job well.  C programmers complain that they
can't do what they do what they want.  But C isn't the answer to every problem
(maybe most, but not all :-).  It would be foolish to re-write (there is that
re-using issue again :-) a database system in C++ simply to be able to use C++
code sharing and OOP features.  Purchase a DBMS and a 4gl that suit your needs
and go with it.
--

 -- Bradley M. Kuhn  

     UUCP:     ...uunet!rhlab!bkuhn

Bill Foote write:-

Quote:

stuff deleted

> That's the key.  No decent C programmer would ever *consider* doing
> it from scratch.  He'd either buy a library that does it, or write
> it once, and put it in a library.  Then he gets the productivity
> gain of having OPEN WINDOW et al., and he doesn't have to suffer through
> some of 4GL's shortcomings.

Yes but what is 4GL if it is not one large C library presented in a
fashion that allows non C programmers to use it.  What does 4GL do -
it precompiles down to C!!  Yes 4GL is not the best thing for all jobs
and it does lack some functions that we would like but it works, it is
reasonably bug free and has been steadily extended to answer the
complaints that people have about it.  4GL++ is to be available
shortly and this should deal with many of the remaining gripes while
"hopefully!"" remaining reasonably compatible with the current
language.

Why pay large sums of money for C programmers when you can buy a
C library and code from it using a reasonable meta language which
most any programmers can pick up and use.  Not only that but I can
library my 4GL code along with additional libraries of C code and
combine the lot into whatever I require.

I take a general view.  You use the tool best suited for the job
whether that is C, 4GL, PERL, C++, shell doesnt matter.  What is best
depends on the costs.  But remember the cost is not just the
development cost.  Maintenance and enhancement is where your cost
really goes up.  It is a waste of money to write in C and then spend
time and effort maintaining that code if it can be maintained more
cheaply in a language (whichever) that is easier to read and
understand.

Quote:

> That said, I concede that 4GL could well be a good tool that helps to write
> a certain class of applications.  It's also probably easier to use than
> C in some senses, and almost surely easier to pick up than C.  But I
> still like C better!  (I also think that Forth is kinda neat, so maybe
> there's no hope for me :-)

None. Its too late you have become a C guru and there is no hope!
Sorry. :-)))

Cheers - Jim
--------------------------------------------------------------------

Company:  DHL Systems Inc          Phone:    (415) 358-5911 (Work)
Address:  1700 S. Amphlett Blvd.             (415) 882-9728 (Home)
          San Mateo, CA 94402      Fax:      (415) 571-6429
--------------------------------------------------------------------

I have used Informix 4GL since 1989, and used ESQL/C for maybe three years
before that.  I guess I just learned to write C programs that use Informix
forms for data input functionality.  Now, when I write applications, they
are still written in C, they just call 4GL functions to do the stuff they
do fairly well.  I retain all the power of C, while gaining the advantages
of Informix forms and database querying.

What I find especially fun is to use cpp to convert generic 4GL proto-
type functions into compilable 4GL.

Quote:>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.

The primary advantage of 4GL (IMHO) is rapid prototyping.  The execution
speed of 4GL programs is at least 10 times slower than of an equivalent
C program. I'll write the user interface using 4GL, then finish the
application in C.

                Of course it's only my opinion!  
                Nobody else gives a damn what I think.

Quote:Jim Gordon writes...

> Why pay large sums of money for C programmers when you can buy a
> C library and code from it using a reasonable meta language which
> most any programmers can pick up and use.  Not only that but I can
> library my 4GL code along with additional libraries of C code and
> combine the lot into whatever I require.

Thanks for your reply to my post.  That's basically what I wanted to
confirm to myself:  That 4GL doesn't have something that I don't suspect
that would make me, personally be a gajillion times more productive
(like the Informix sales literature would have me believe).

I *definitely* believe that 4GL is a great tool in an environment where
one can have a bunch of 4GL programmers with a couple of C programmers
for when one really needs C!

Quote:> I take a general view.  You use the tool best suited for the job
> whether that is C, 4GL, PERL, C++, shell doesnt matter.  What is best
> depends on the costs.  But remember the cost is not just the
> development cost.  Maintenance and enhancement is where your cost
> really goes up.  It is a waste of money to write in C and then spend
> time and effort maintaining that code if it can be maintained more
> cheaply in a language (whichever) that is easier to read and
> understand.

But C is so very easy to read!  :-)

Well, it's more readable than Lisp, anyway.

(Seriously, for me C is very readable, but I admit that I'm perhaps
not the typical case.)

Quote:>>  <is there any hope for me?>
> None. Its too late you have become a C guru and there is no hope!
> Sorry. :-)))

Shucks.  My parents had such high hopes, too...

Bill
--

PDS Corp, Los Angeles, CA  USA                          uunet!promdist!bill