hascall@atanasoff.cs.iastate.edu (John Hascall) (08/30/89)
One problem, as I (and quite possibly, I alone) see it, in computer
programming* today is the feeling that we have to make allowances
for every quirky little idea that occurred in the past (we all hush
our voices and whisper, "ooh, but it's prior art"). It may be prior,
but a lot of it is far from art. Isn't it time we took a careful look
at some of the baggage we're dragging around? Can't we just admit that
some of it is really more trouble than it's worth.
All the (proposed) ANSI C standard seems to have done is made every
quirky little implementation "official". If it didn't follow the
spirit (or even the word of) K&R, so what we'll just expand the
standard a little.
Other scientific and engineering disciplines have managed to shed
their past false steps, why can't we?
Some items I would like to see investigated by the "committee on
un-American programming activities":
# of bits in a byte
# of bytes in data types
character encoding
integer data format (signing schemes, etc)
floating point data format
endian-ness
internal value of NULL pointer
a constant pointer size
interpretation of shift operations
(others I'm sure)
Now I realize how much trouble it would be to pin all these down this
late in the game, but it sure would make writing portable code a lot
easier (it would almost come automatically, which would be quite a plus
given the dearth of attention paid to portability in CS courses).
* it seems a little premature to use everyone's favorite buzzword "software
enginnering"--engineering seems to connote a certain amount of precision
which, so far, seems not to be evident in the tools of our craft.
Just another one of my silly little jihads,
John Hascall
p.s. If you're all tired of my ramblings you could pitch in and get me
a faster workstation and I wouldn't have so much "compile-wait-time"
to think(?) up these things. :-)
pps. Oops, it's time to call my domestic engineer and have her put the
sanitation engineer's package on the curb. :-) x 2
How come everyone wants to be a _________ Engineer, and no one wants
to be a Doctor of ______________ or an Attorney at ___________??!flaps@dgp.toronto.edu (Alan J Rosenthal) (08/31/89)
hascall@atanasoff.cs.iastate.edu (John Hascall) writes: > Some items I would like to see investigated by the "committee on > un-American programming activities": Ok, I'm un-American, so I'll have a go. I'll split your topics up into a few categories. The first category is "Doesn't Matter As Long As You Write Your Programs Correctly". ># of bytes in data types Would you prefer writing "malloc(4)" to "malloc(sizeof(int))"? Other than that, why does it matter? >endian-ness This is usually hard to observe except in unusual circumstances (network stuff) or bizarre unportable programs. And in most of the situations in which it comes up, the data would have been better written in text form rather than binary, for human readability. It's true that there are situations in which endian-ness is important, but for that see the third category. >internal value of NULL pointer This is impossible to observe in correctly written programs. The next category is called "It Might Be Looking Towards The Future As Well As Looking To The Past". To constrain the following would make C obsolete at some point in the future as things get bigger: ># of bits in a byte ># of bytes in data types >character encoding Character encoding will have to change as character sets encompass more languages and more symbol sets (integral signs etc). [ I repeated the "# of bytes in data types" item. ] This category is called "People Expect C To Be Efficient, And They Expect This Efficiency To Result From C Being Close To The Machine, And Machines Are Different In These Regards". >interpretation of shift operations >integer data format (signing schemes, etc) >endian-ness [ I repeated the "endian-ness" item. ] The final category (miscellaneous): >floating point data format Well, ansi C doesn't constrain this, but neither does it constrain keyboard layout. However, keyboard layout is certainly important to me, as is floating point format to some. You can always insist on ansi C with IEEE floating point, and I'll insist on a C compiler on a machine with a reasonable keyboard. >a constant pointer size I don't know what this means, but if it means that all pointers should have the same representation, it's in the first category. -- There are many problems with ansi C, but I don't think any of the above points represent problems with ansi C. They represent ways in which ansi C has recognized the diversity of C environments over space and time. The diversity of C environments represented by the above points is good. There are other aspects of the diversity of C environments that are not good. These include monocase or six character external identifiers, bizarre file systems or file types, and the common versus ref/def disparity. ajr
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/31/89)
In article <1418@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes: > All the (proposed) ANSI C standard seems to have done is made every > quirky little implementation "official". That's definitely not true. Implementations were allowed freedom where it was obviously necessary, and where C's use as a systems programming language required it. This is not new; C has always had these loosities. In many ways the proposed standard requires existing practice to be "tightened up". > Other scientific and engineering disciplines have managed to shed > their past false steps, why can't we? They don't close down old, safe bridges simply because a new bridge design would be better in the light of current knowledge. > Some items I would like to see investigated by the "committee on > un-American programming activities": > # of bits in a byte > # of bytes in data types There is no reasonable defense I know of for over-constraining these. I don't even LIKE bytes, and I sure don't want to be told that my computer designs have to provide exactly 8-bit chunking. > character encoding > floating point data format There are standards for this, but they're not universally adopted. I guess it was hard to convince people that they should discard billions of dollars' worth of existing equipment and software. > integer data format (signing schemes, etc) > endian-ness > interpretation of shift operations There are good arguments for allowing freedom for these designs. > internal value of NULL pointer This one is nobody's business. > a constant pointer size This one would serve no useful purpose and would be problematic for word-oriented (i.e. FAST) architectures. etc.
karl@haddock.ima.isc.com (Karl Heuer) (08/31/89)
In article <1418@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes: >Some items I would like to see investigated by the "committee on >un-American programming activities": > # of bits in a byte > # of bytes in data types > endian-ness >[etc.] If the X3J11 Committee were to close its collective eyes and wish real hard, would all the machines that aren't VAXen just disappear, or what? How can you possibly nail down something like this in a language standard? >it sure would make writing portable code a lot easier If all machines were alike, moving code from one to another would not be a "port" by the current meaning of the word. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
gordon@sneaky.UUCP (Gordon Burditt) (08/31/89)
> All the (proposed) ANSI C standard seems to have done is made every > quirky little implementation "official". If it didn't follow the Look at your list more carefully. It makes most every quirky HARDWARE implementation usable if you try hard enough. It addresses nothing about compilers that don't catch errors, or have strange quirks that make people think they are actually features, as in: # define ctrl(x) 'x' which is better defined as # define ctrl(notused) 'x' because they should do exactly the same thing. > spirit (or even the word of) K&R, so what we'll just expand the > standard a little. > > Other scientific and engineering disciplines have managed to shed > their past false steps, why can't we? It is interesting that the "mistakes" to be shed are HARDWARE "mistakes", for the most part, not software mistakes, like dereferencing NULL pointers. > > Some items I would like to see investigated by the "committee on > un-American programming activities": Won't do any good. Contact the "committee on un-American CPU Design". > # of bits in a byte Hardware. > # of bytes in data types Constrained by hardware with some limited choices available to software. > character encoding Largely constrained by character sets used by terminals and printers, and efficiency considerations. > integer data format (signing schemes, etc) Hardware. > floating point data format Hardware, except for machines with pure software emulation of floating point. > endian-ness Hardware. Although it's possible to "fight" this, it introduces extreme inefficiency. > internal value of NULL pointer Often very limited by hardware memory management schemes. > a constant pointer size If the hardware doesn't cooperate, this can result in significant overhead, like many pointers occupying twice as much space as they should. > interpretation of shift operations Fighting the hardware here can result in significant overhead. > Now I realize how much trouble it would be to pin all these down this > late in the game, but it sure would make writing portable code a lot > easier (it would almost come automatically, which would be quite a plus > given the dearth of attention paid to portability in CS courses). Increasing portability by restricting the scope so you don't have to worry about the quirks of that implementation doesn't increase the number of machines it will run on. It just says "we won't bother with porting to that; it's too wierd, but so we can still call this code portable, we'll outlaw it". Writing unportable code and then re-writing the spec to call it portable doesn't make it any more portable. Gordon L. Burditt ...!texbell!sneaky!gordon
henry@utzoo.uucp (Henry Spencer) (09/06/89)
In article <1418@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes: > All the (proposed) ANSI C standard seems to have done is made every > quirky little implementation "official"... You obviously weren't around for the Reiserism Wars, when a good many people rose in outrage because X3J11 disallowed some undocumented, ugly, poorly-thought-out "features" of the Reiser C preprocessor (used in most Unix C compilers). It is most unlikely that *any* pre-X3J11 implementation is standard-conforming without changes. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mouse@mcgill-vision.UUCP (der Mouse) (09/16/89)
In article <1989Sep5.224525.634@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <1418@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes: >> All the (proposed) ANSI C standard seems to have done is made every >> quirky little implementation "official"... > You obviously weren't around for the Reiserism Wars, when a good many > people rose in outrage because X3J11 disallowed some undocumented, > ugly, poorly-thought-out "features" of the Reiser C preprocessor > (used in most Unix C compilers). ...and replaced them with ugly, poorly-thought-out features. At least the new ones are documented. I suppose this is progress. Why do I say ugly and poorly thought out? It's inextensible and confusing, when it would have been so *easy* to do it in a nice extensible, unconfusing, and no more incompatible[$] manner! #define paste(foo,bar) foo ## bar /* what the dpANS says[%] */ #define paste(foo,bar) foo #paste bar /* what I would recommend */ #define stringize(foo) # foo /* what the dpANS says[%] */ #define stringize(foo) #string foo /* what I would recommend */ [$] Unless the compiler I mention in the next paragraph exists. [%] I may have the dpANS # and ## interchanged. See next paragraph. Clean. Easy to keep straight which is which. Easy to extend when you want to do something else strange with macro arguments. Was something like this proposed? (Surely.) Why was it turned down? Was there - gack! - some compiler that already used # and ## (aka "prior art")? Ah well, at least it's better than what we had. Now everyone will use the *same* ugly features. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu