Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!tomr
From: tomr@dbase.A-T.COM (Tom Rombouts)
Newsgroups: comp.databases
Subject: In defense of Clipper 5.0
Keywords: Clipper
Message-ID: <1991May17.170054.18080@dbase.A-T.COM>
Date: 17 May 91 17:00:54 GMT
Reply-To: tomr@dbase.UUCP (Tom Rombouts)
Organization: Ashton-Tate
Lines: 73

Well, as much as I hate to do it, and knowing it is of no interest
to the Oracle, Informix, Ingres, Sybase and Unify (the top five UNIX
database products, according to a graph in the current Sun Expert)
people who dominate this group, I would like to make some comments on
Clipper 5.0 in an attempt to reduce the overall signal-to-noise ratio.

1. 5.0 was a very ambitious revision.  An implementation of user
defined commands was introduced, new roughly C-like structures were
added to the language, new linking technology was included in the
box, and the (somewhat infamous in the first release) VMM system was
included to name some of the major changes.  I think it is a pretty
good job technically.  IMHO, Clipper has been over-hyped by some
prominent people, however.  One could say that due to our market
driven, promotion-oriented economy, almost all commercial software
that has had a lengthy promotional campaign ends up being disappointing
to many people once it is actually released.  One's expectations,
if incorrect, should not overshadow what was actually accomplished.

2.  Now, more than ever, Clipper is a tool for advanced users.  In its
earlier days, what was Clipper?  Why, "The dBASE compiler," of course.
You often prototyped in dBASE III+, then, perhaps using a slew of
IF CLIPPER constructs, compiled the final version.  Of course, those
days have long passed.  As the recent postings shold demonstrate, 
knowledge of linking and DOS internals such as memory allocation
or file handling are more important than ever to debug Clipper problems,
no matter whose fault (the user's code or Clipper itself) the problem
really is.  Although some wanting to maximize total unit sales of
Clipper may disagree, Clipper, despite its typlical use of dBASE-like
(that is, English-like) syntax is simply not a tool for beginners.
Their tech support, as some have discovered, seems to imply this as
well.  If it is not obvious by now, try to plug yourself into the
Clipper user world (User groups, BBS, newsletters, NANFORUM) as 
much as possible for de facto tech support.

3.  5.0 works best with 5.0 syntax.  As far as I can tell, most of
the beta testers for 5.0 seemed to be more advanced users who were
very eager to use the new constructs of the language.  IMHO, upward
compatability with Summer '87 code that worked (note I do not say
it was "proper" syntax) was not the highest priority.  (Also, many
people do not seem to understand that many third-party libraries
access internal Clipper information that was specific in location or
content to a specific version.  If this is the case, you need a new
version of the library from the library vendor.  If one is not 
available, you will simply have to change your code or functionality.)
Since no DOS 4GL that I know of includes a BNF grammer with it,
the functionality of the language must be determined from actual
operation.  In short, do not assume that any Summer '87 code 
application will necessarily work unchanged in 5.0.
 
In summary, Clipper 5.0 is very good for what it is, a fairly
English-like 4GL for rapidly developing DOS database applications.
However, it does not have the ease of use of Turbo BASIC, it is
not portable or optimized like C, and it is certainly not an
environment like Smalltalk or InterLISP.  It does provide a very
good time/performance trade-off to develop .EXE applications.
But one should be very aware going in of what it does and does not
provide, at least in the current incarnation.  The problems that
some people have with 5.0 are in some cases actually problems with
choosing the right tool for the job.

IMHO, the developers and technical experts advocating Clipper (such
as Tom Leylan) are very knowledgable.  However, some of Nantucket's
marketing and promotion people seem to have gotten carried away
at times, and obviously tech support and documentation is not 
Nantucket's highest priority.  (BTW, if you do not have Rick Spence's
book on 5.0, run, don't walk, to get a copy of it!  He is probably
too modest to mention it, but it is my understanding that Tom Leylan
contributed quite a bit to it.) 

And may the debates continue!


Tom Rombouts  Torrance 'Tater  tomr@ashtate.A-T.com