Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site ea.UUCP Path: utzoo!linus!decvax!tektronix!uw-beaver!cornell!vax135!houxm!ihnp4!inuxc!pur-ee!uiucdcs!ea!mwm From: mwm@ea.UUCP Newsgroups: net.lang.c Subject: Re: C needs BCD (ANSI People: Please Lis Message-ID: <5700028@ea.UUCP> Date: Thu, 8-Nov-84 12:51:00 EST Article-I.D.: ea.5700028 Posted: Thu Nov 8 12:51:00 1984 Date-Received: Sun, 11-Nov-84 20:48:18 EST References: <218@x.UUCP> Lines: 71 Nf-ID: #R:x:-21800:ea:5700028:000:4065 Nf-From: ea!mwm Nov 8 11:51:00 1984 /***** 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.