Re: WANTED: InfoWorld Editorial, August 18, 1980, Vol.2, No.14, p.8

Hello, Jeffrey!

However, that issue is in a strange place.
It is appended to the end of the September 1, 1980 issue.

Egad! I did not have the idea of searching there! Thanks!

Yours Sincerely,
Mr. Emmanuel Roche, France


IW2-17.WS4 (= CBASIC editorials)
----------

- "Editorial"
"InfoWorld", 18 August 1980, Vol.2, No.14, p.8

(Retyped by Emmanuel ROCHE.)


For the last two or three years, CBASIC has been the primary
language for the development of commercial CP/M applications
software. Although CBASIC is not an optimum language, three
factors contribute to its popularity.

A lot of people, some of whom have encountered various forms of
BASIC in high-school or college introductory programming
courses, can easily learn it. Use of CBASIC permits the
distribution of software without the need to supply source code;
this ensures that customer modifications and their accompanying
support problems can be controlled. It also produces the
illusion of security from piracy in the minds of software
entrepreneurs.

Finally, CBASIC provides an essentially royalty-free environment
in which to distribute software. Although each user must
purchase a copy of CBASIC, he only has to do it once, and it
does not involve any record keeping on the part of the
applications-software vendor.

These features ensure the success of CBASIC in the marketplace,
despite some serious drawbacks.

The language is probably the least interactive dialect of BASIC
commonly available. Programs must run through the pseudo-
compiler before any error checking is performed, making
debugging tedious. Despite this use of a pseudo-compiler, and a
run-time intermediate code interpreter, CBASIC is not one of the
faster BASICs. Programs must be carefully optimized for speed.

In addition to the lack of speed and the clumsy development
mode, CBASIC has long suffered from reliability problems. The
language has gone through one major revision and many minor
ones. The major revision added features to the language, but at
the expense of making the intermediate code, which had been
compiled by the first version, incompatible with the produced by
the second. This required many users to purchase both versions
in order to run both new applications and previously-purchased
software.

One major producer of applications programs provides a special
"enhanced" version of CBASIC, for his software. The enhancement
consists of patches to the language, without which some programs
will not run.

For these reasons, the microcomputer software community
jubilantly greeted the announcement of the Microsoft BASIC
compiler. Microsoft interpreted BASIC has had an honorable
history in service to software developers on many different
machines. Since Microsoft has preserved compatibility between
the interpreted and compiled BASICs, programs can be developed
in an interactive mode. When they are fully debugged, they can
be compiled to provide a fast running package for which the
source code need not be distributed. This combination provides a
nearly ideal environment for the development of commercial
software in BASIC.

Alas, the technical environment is not the entire world.
Microsoft has a surprise or two for the small software developer
in the licensing agreement. The license requires payment of a
per-copy royalty of 9% of the retail price for software
products, and $40 for hardware/software combinations.

With author royalties running at 10% to 25% of the retail price
of a program, a 9% royalty to the language developer could make
software development downright unprofitable. The $40 fee for
hardware/software combinations means the license fee will
comprise more than 10% of the manufacturer's cost for products
costing less than $650. With entire computers becoming available
for under $200, these costs seem unreasonable.

The final blow to a small-software developer is that, in order
to enforce the royalty provisions of the licensing agreement,
Microsoft has reserved the right to audit any and all of the
developer's records relating to distribution. Microsoft has a
consumer-products division, and is, therefore, in direct
competition with many of the potential users of the compiler. It
is unlikely that a software entrepreneur will relish the thought
of opening his books to the competition on demand.

We do not quibble with Microsoft's right to license their
products under any terms they see fit. It is disappointing,
however, to find that a badly-needed product is being offered in
the marketplace under terms that may preclude the acceptance it
would, otherwise, deserve. CBASIC has impaired software
development for too long. Microsoft has the technical solution,
but nor the economic one.


- "Viewpoint"
Gordon Eubanks
"InfoWorld", 29 September 1980, Vol.2, No.17, p.10

(Retyped by Emmanuel ROCHE.)


An editorial in the August 18 (1980) "InfoWorld" made naive
generalizations about the contributions of CBASIC to the
microcomputing community. Such inaccurate reporting reflects
poorly on your publication. Editorial content should be based on
adequate research, and must present conclusions that are
supported by facts.

The implication that using a compiler equates to clumsy
development ignores the features in many compilers that assist,
rather than hinder, the programmer. Do you consider FORTRAN,
PL/I, and Pascal inferior? Free format source statements, no
penalties for comments, and the ability to include many source
files during compilation are certainly advantages. The choice of
a compiler or interpreter is dependent on the application, and
quite naturally will vary.

The editorial implied CBASIC is slow. First of all, CBASIC
maintains numeric quantities as 14-digit Binary-Coded Decimal
numbers. This provides adequate accuracy for financial
applications, and insures accounts balanced to the penny. Even
double-precision binary formats cannot make this claim. However,
detailed testing of string processing and file accessing, the
cornerstone of most business applications, reveal that CBASIC is
faster than most other BASICs on the market. The narrow scope of
most benchmarks is misleading the industry. "InfoWorld" could
make a contribution to the microcomputing community by
establishing tests for software across a spectrum of
applications.

It seems obvious that, to use the features offered in Version 2
of CBASIC, one would need to purchase Version 2. All registered
users of Version 1 were given a substantial discount on our new
product. In addition, vendors had the option to provide both
versions to their customers. As a matter of interest, the reason
Version 2 was incompatible with Version 1 was that the run-time
environment was modified to support new features such as
chaining. The source code remained compatible.

Compiler System's policy is to support users with the best
possible products. When warranted, new releases of CBASIC have
been issued to correct bugs and improve performance. They are
provided by Compiler Systems to the 15,000 registered users for
only a disk-copying charge. Licensed distributors may update
registered users without any payment to Compiler Systems.

To provide the widest market for applications developed in
CBASIC, Compiler Systems provides a number of CBASIC
configurations. This allows programmers to use the full
capabilities of a particular system. For this reason, a separate
configuration is provided for the TRS-80 Model 1, and for use
with MP/M and CP/M Version 2. There are no incompatibilities
among those configurations. Compiler Systems is currently
working on two new configurations that will significantly expand
the availability of CBASIC.

Presenting CBASIC as unreliable in comparison to the BASIC-80
compiler is a gross misrepresentation of fact. CBASIC has been
available when announced, shipped when ordered, and reliable
enough to implement a majority of the business applications
written for the CP/M and MP/M environment. It is the features of
the language that attract applications programmers to CBASIC.

Gordon E. Eubanks, Jr.
President
Compiler System, Inc.
Sierra Madre, CA


- "CBASIC: Two views"
"InfoWorld", 13 October 1980, Vol.2, No.18, p.11

(Retyped by Emmanuel ROCHE.)


The editorial in "InfoWorld" Vol.2, No.14, failed to adequately
highlight the specific problems with CBASIC. Such highlighting
would have save me many frustrating hours.

The CBASIC manual led me to believe that programming in CBASIC
would be easier than in other languages. In practice, CBASIC
proved to be counter-productive. The author combined the worst
features of compilers and interpreters. This so-called compiled
language runs slower than any interpreted BASIC I have
encountered, while being just as difficult at debug time as any
compiler.

I spent the majority of my time fighting the language, rather
than performing productive work. CBASIC appears to have a
problem managing its scratch memory. I crashed two different
systems by opening more files than I had room to buffer, and
performing long string concatenations on the same line. Other
random crashes were hard to isolate. Many times, run-time errors
referred to non-existent lines and meaningless errors.

The most shocking quirk in the language is the author's
misunderstanding of BASIC string comparisons, which are defined
as lexicographical. CBASIC performs numeric string comparisons.
This means, for example, that CBASIC concludes that the word
zebra belongs before alphabet, and that xylophone belongs after
both zebra and alphabet. This makes sorting and searching
alphabetic data difficult in this language; that CBASIC does all
string subscripting with the functions LEFT$, RIGHT$, and MID$
does not help, either.

I was trying to solve a problem requiring a series of programs
chained together. One program was designed to help users by
explaining commands. CBASIC requires that memory be split into
four pieces: one for constants, one for variables, one for code,
and one for DATA statements. All programs in a chained series
must have the same partitioning.

This meant I had to carry the large DATA area of the explanation
program with all of the other programs in the series, even
though they did not use any DATA statements. When space became
tight, I had to reduce the number of DATA statements in the
explanation program to add more lines of code to a different
program. I know of no other language, compiled or interpreted,
with such a requirement.

I will compliment CBASIC's file structure: it has both
sequential and random access files, which are easier to use than
those of Microsoft BASIC. CBASIC falls short because it has no
binary files, and the ASCII delimiters take up to three bytes
per field. The most important problem is CBASIC's lack of an ON-
ERROR statement. The file system is also inexcusably slow.

CBASIC illustrates why companies that ultimately buy
microcomputers do not take microcomputers seriously. The problem
is not hardware performance; it is software performance.

Why, then, do some big software houses initially choose this
language? Whatever the reason, the front-page story in
"InfoWorld" Vol.2, No.16, indicates that I am not the only ex-
user.

Kevin McDonnell
San Bruno, CA


I take issue with the editorial attack in the August 18 (1980)
issue upon CBASIC. The editorial took umbrage with CBASIC
because it is slow. Apparently, Aesop's fable about the turtle
and rabbit race, and the lesson it taught, has been lost to the
editorial's author. CBASIC is easy to use, and has excellent
file-handling and string capabilities. It gets you where you
want to go, and is one of the most economical software packages
around. This is what appeals to the "Woolworth" trade for
everyday, simple use. How the author comes to the final
conclusion that "CBASIC has hampered software development for
too long" will probably remain a mystery, since CBASIC is and
has become the teething ring for almost all neophyte computer
programmers; experienced programmers still use it.

The editorial author should consider taking more antacid tablets
before he is allowed any more free literary license in
"InfoWorld".

Allan Louderback
Temple City, CA


EOF

.

Relevant Pages

  • Re: Linked Lists debugger question
    ... With C++/CLI extensions, you can use this RAD paradigma for building GUIs ... I don't think I will be doing any web based applications. ... It has both a very good IDE and a very good C++ compiler. ... it still the language of choice for develloping PC based applications? ...
    (microsoft.public.vc.language)
  • Re: Generating a simple hand-coded like recursive descent parser
    ... complexity of the language at the parsing level. ... Most BASICs are LLand quite easy to parse, ... hand-coded recursive descent parser? ... If you want to write your compiler in BASIC, ...
    (comp.compilers)
  • Re: Generating a simple hand-coded like recursive descent parser
    ... compiler is for an existing BASIC language. ... Maybe because it is my first compiler is just seems complicated. ... various BASICs. ... built all data structures manually in the recursive descent parser. ...
    (comp.compilers)
  • Re: Bounds checked arrays
    ... > more at each array access will not make any ... But for those applications which are real-time ... > When the state of this toggle is ON, the compiler ... The C language has a long-standing tradition ...
    (comp.lang.c)
  • Re: Use of ; in Forth Compiler
    ... It makes the operation of your language a bit clearer than your usual stream of content-free "Forth is dysfunctional!" ... it sounds like you're compiling into a temporary buffer and then copying the code to the final destination. ... I'm curious if you keep statistics (or if your compiler can be extended to keep statistics) on the average and maximum length of definitions. ... I'm not putting in things my applications don't require. ...
    (comp.lang.forth)