C needs BCD (ANSI People: Please Lis

[mwm at ea.UUCP]

/***** ea:net.lang.c / ihuxn!res /  8:48 pm  Nov  5, 1984 */
I would like to take this last remark more seriously than the author
intended.  Let us assume that we had to choose between FP and BCD.  How
should we choose TO SERVE THE LARGEST NUMBER OF CUSTOMERS.  Back in
1975 a side effect of some work I was doing was discovery that a large
fraction of the programs being written were business programs written
in COBOL.
					Rich Strebendt
					...!ihnp4!ihuxn!res
/* ---------- */

Rich, I think you are suffering a delusion about what languages are for.
Languages (usually, anyway) aren't designed and implemented to try to serve
as many "customers" as possible, they are designed (well, sometimes :-) and
implemented to fill a need; generally a need felt by *one* customer. ADA is
a perfect example, XLISP another.  If that language fills that need for
that customer then it is an unqualified success. If it happens to fill some
need (maybe not the same one!) of many other people as well, and gets
wide-spread use, then it we call it "successful".

I can't speak for Ritchie, but I use C because I need a high-level systems
programming languages. Given the history of C/Unix, I suspect that that is
what it was designed for originally. Though C has grown some since I first
started using it (v6), it still fills that need. Such usage calls for
pointers (dangerous beasts), a looseness about types (not all that safe in
a compiled language), and *lots* of integer arithmetic. It also calls for a
little fixed and/or floating point arithmetic. On the machines I use, it
*never* calls for BCD arithmetic.

C is not a be-all and end-all for programming languages. I've never
encountered a language that is, and never expect to. When I step outside
the systems programming environment, I change languages.  FORTRAN for
number crunching (C isn't suitable, due to the float/double problem, the
way it handles arrays, and a certain laxness about expressions), LISP for
symbol shuffling and as a programmable calculator, ICON for string work,
and CLU for general applications work. Of course, awk/sed/sh get used quite
a bit, too.

C does handle the systems work well, and has almost all the facilities I
need. There are some minor things I'd like to see added to improve it's
usefulness *in that area*. What I wouldn't like to see are extensions for
things outside that area (you need to choose a better tool, not remake one
that doesn't fit), or changes that make it more suitable for something
outside that area while making it less suitable for work inside the area.
Adding a BCD type fits in the first category, changing the array
subscripting scheme to look like FORTRAN falls into the second.

For the barb, just because a feature is highly used in one tool, doesn't
mean that it should be added to them all. By that argument, the first thing
that needs to be done to C is to make it compatible with the most popular
language on Unix, the Bourne Shell. I don't think anyone would advocate
that. :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

Now, just to help, I'd like to make a suggestion. If you *really* want BCD
in a C compiler, you can follow COBOL. Change *all* the integer types to
BCD in various sizes. Since most of those COBOL programs run on IBM
hardware, you could satisfy a large portion of your customers with one
compiler. Or you could put in real BIGNUMs instead of BCD. Just think, the
code would still compile and run under a normal C compiler.  Of course,
you've just destroyed C for systems work, so you might as well change the
array data type to fit your needs, add stricter type checking to make your
code safer, remove those dangerous pointers, replace all the cryptic magic
cookies with real words, etc. Trouble is, what you end up with isn't C,
it's a language designed to meet your needs.

Maybe it would be better to start from scratch, and build a modern language
that fits the needs of the DP community? That would seem to be an
intuitively better route than trying to bend a systems tool to those needs.

	<mike