The weird thing about this perspective is that in the year 2000,
programmer time and effort are worth far, far more than a bit of
machine performance.  Maintenance is easier on 4GL code too, at
least if it isn't too complex and tricky (but the same can be said
for 3GL).

Much is done today with perl, php, and many other scripting languages.
These provide good productivity for programming as glue to integrate
solutions, but these solutions have problems with stability and
robustness.  Why don't our 3GL languages provide the integration that
we can find only with these tools?

4GL were supposed to make coding easier, but also to provide a rich
set of capabilities and functions so programmers wouldn't have to
reinvent the wheel and so every shop wouldn't need a guru programmer.
Originally, PH provided this (I for one think Quick screens provided
very rich capabilities and usability for users), but over time less
and less was done to keep PH up with the developing technologies
and with user needs for integration, so more and more coding and
complexities and other tools got introduced in trying to keep
solutions up to date.

The idea of a 4GL is perfect for today.  We need high programmer
productivity and to provide many, rich features to our users.  We
don't need to be writing error traps and integer to "pretty print"
numeric conversion routines.  VB, with all the add-on controls and
functionality available from 3rd parties, is probably the closest
to this today, but it, too, suffers from stability and compatibility
problems and it doesn't provide cross platform functionality (which
is a very real requirement - particularly in an e3k shop).

So today, instead of a grown up PH or a cross platform VB, the
marketplace gives us Java and Oracle. (Now, if you want some hard
to use and ugly screens, try Oracle forms.)  Java at least offers
the promise that if you master enough existing classes and design
good objects, you can almost code like it was a great 4GL.

Richard


Joseph Rosenblatt wrote:
>
> Both COGNOS and SPEEDWARE share the same two basic failings.
> 1. Neither one is a serious programming language a trait they share with all
> "user friendly", 4GL,Reportwriters, Basic based and otherwise "higher level"
> languages. These languages sacrifice flexibility for "ease of use." I never
> found COBOL, FORTRAN or assembly languages so difficult that I needed to be
> saved from the bother by a new and totally proprietary set of "easy to use"
> rules.
> 2. They both have the same predatory pricing a trait they share with a lot
> of other software companies. Down with "Tierany."  (Tierany  is the use of
> hardware tiers in determining software prices.)
>
> Joseph "I wish I could Code in Machine Code" Rosenblatt


--
Richard L Gambrell,
Database Administrator and
Consultant to Computing Services at UTC

  University of Tennessee at Chattanooga
  113 Hunter Hall, Dept. 4454
  615 McCallie Ave., Chattanooga, TN 37403-2598
  voice mail/cell phone: 423-432-5122
  private email: [log in to unmask]
  office fax: 423-755-4025
  office phone: 423-755-4551
  UTC email: [log in to unmask]