jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) (04/21/89)
A "I was just wondering" question:
Why is C case-sensitive? I suppose it allows the
lexical analyzer in a C compiler to be a bit faster,
but certainly not much faster. UNIX itself is
case-sensitive, of course, but certainly C need not be.
So...why?
-- Jeff Kuskin, Dartmouth College
EMAIL: jskuskin@eleazar.Dartmouth.EDUbph@buengc.BU.EDU (Blair P. Houghton) (04/21/89)
In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: >A "I was just wondering" question: > > Why is C case-sensitive? I suppose it allows the 1. 26 letters and ten numbers are not enough for all the names you use. Try looking at some old IBM 370 assembler code sometime, if you can get around the hash-table program-naming system they forced on programmers... (geee-yuck!) 2. Huminz iz not cumpooterz. We like it that way, and we make the silly microchips do what WE ask. You get the same sort of thing in a PI/grad-student relationship, too (urf!.. murfle... okay, leggo. Sorry... forget I mentioned the PI... :) 3. Be glad it's not the whole of the APL character set. Imagine six kinds of Oh's, and more control-keys than an emacs engine. 4. It goes along with the generality, modularity, and uninhibitionist attitude of C. I think there's more than one way to get the entirety of ascii into your code as parts of identifiers. I'm not the pathologue to catalogue such things, however. (Where's Andy Koenig when you need him? 2x:-) 5. BeCaUsE. --Blair "Well, that's the reason I grew up on. You can relate, can't you? Whaddaya mean, this ain't Group? I been coming here for weeks!"
chris@mimsy.UUCP (Chris Torek) (04/21/89)
In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: >A "I was just wondering" question: > > Why is C case-sensitive? BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/21/89)
In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: > Why is C case-sensitive? It makes programs considerably more readable, and expands the available name space considerably. Is there some reason C should NOT be case sensitive?
R.DHESI@BSU-CS.BSU.EDU (RAHUL DHESI) (04/22/89)
In article <10088@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Is there some reason C should NOT be case sensitive? BACK WHEN THEY WERE THINKING ABOUT INVENTING THE FIRST KEYPUNCH, THEY HAD AN IMPORTANT DECISION TO MAKE: SHOULD THE KEYPUNCH BE ALL LOWERCASE OR ALL UPPERCASE? AFTER MUCH THINKING THEY SAID LETS MAKE THEM UPPERCASE BECAUSE THEIR SO MUCH EASIER TO REED. I THINK THIS WAS A WISE DECISION. EVEN MICROSOFT AGREES WITH ME BECAUSE WHEN I BOUGHT MICROSOFT FORTRAN FOR MY TRS-80 IT SAID WE RECOMMEND USE UPPERCASE BECAUSE IT'S EASIER TO REED. ALSO THE COMPILER WAS SMART ENOUGH TO CHANGE ALL LOWERCASE TO UPPERCASE IN LISTINGS IN CASE THE PROGRAMMER FORGOT. BESIDES STANDARD FORTRAN SAYS YOU BETTER NOT USE LOWERCASE BECAUSE IT ISN'T IN THE STANDARD, AND ADA SAYS YOU BETTER NOT DO THE SAME THING EITHER. SO CONCLUSION I THINK LOWERCASE IS NOT GOOD. THAT'S WHY IT'S CALLED C (IN UPPERCASE), BESIDES AT&T AGREES WITH ME THAT IT'S "UNIX" IN UPPERCASE. -- RAHUL DHESI <R.DHESI@BSU-CS.BSU.EDU> UUCP: ...!{IUVAX,PUR-EE}!BSU-CS!R.DHESI
raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) (04/22/89)
In article <10088@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >> Why is C case-sensitive? >It makes programs considerably more readable, and expands the available >name space considerably. I think you confuse the ability to use both upper and lower case and the concpet of whether or not upper case characters are unique from lower case. (Translation: You can use upper and lower case in a non-case sensitive language. Hence by your metric, they are both readable.) >Is there some reason C should NOT be case sensitive? I agree that they improve your namespace, but not in any usable way. (Sort of like the big gear/little gear combinations on a bike. You can use them, but it's not a good idea.) Although its debatable, I feel its bad style to use the same name (in diffrent cases) for different purposes within a program. Sure, I like to put my constants (i.e. #defines) in all uppers and variables in lowers, and stuff like that. This does not mean that I'll use "CONFUSING" and "confusing" within a program. I will use "CLEAR" and "coherent" within a program. To a certain extent, programming is an art of juggling many details. By having "QwErtyuioP" and "qWertyIOp" be the same object, I avoid having to remember this non-semantic detail. (Of course this only affects me when I use opc (other people's code).) -- Eric A. Raymond (raymond@ptolemy.arc.nasa.gov) G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James
jlg@lanl.gov (Jim Giles) (04/22/89)
From article <2617@buengc.BU.EDU>, by bph@buengc.BU.EDU (Blair P. Houghton): > In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: >>A "I was just wondering" question: >> Why is C case-sensitive? I suppose it allows the > [...] > 2. Huminz iz not cumpooterz. We like it that way, and we make the > silly microchips do what WE ask. [...] But, I _don't_ like it that way. Ask any literate human whether "Tree" means something different than "tree" and you'll find out that most humans aren't case sensitive most of the time. > 5. BeCaUsE. Most people would find this just plain annoying. . .
jlg@lanl.gov (Jim Giles) (04/22/89)
From article <17037@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu > (Jeffrey Kuskin) writes: >> Why is C case-sensitive? > BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see. Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see" has a different _MEANING_ from "Because people are case sensitive, as you can now see?" The fact is that most people are _NOT_ case sensitive with respect to the _MEANINGS_ of the words. So, computer languages probably shouldn't let case effect the meaning either.
john@frog.UUCP (SuperUser) (04/22/89)
In article <13159@dartvax.Dartmouth.EDU>, jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: > A "I was just wondering" question: > Why is C case-sensitive? I suppose it allows the > lexical analyzer in a C compiler to be a bit faster, > but certainly not much faster. UNIX itself is > case-sensitive, of course, but certainly C need not be. > -- Jeff Kuskin, Dartmouth College An "I just can't help myself" answer: This question comes from the place where [A-Z], [A-Z][0-9] was the state of the art in variable naming schemes... (plus, of course, an optional $ to indicate a STRING variable) -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (04/23/89)
(This issue may soon begin to get on people's nerves. I think there should be a newsgroup dedicated to controversial issues of interest to everybody in the computer-related fields. Perhaps it could be called comp.tech-issues. Then when a flame war is about to begin, people can redirect it to comp.tech-issues.) The issue here is whether C ought to be case-sensitive. Italicized words are here enclosed in vertical bars in my discussion. In article <12481@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive, >as YOU CAn noW see" has a different _MEANING_ from "Because people are >case sensitive, as you can now see?" The fact is that most people are >_NOT_ case sensitive with respect to the _MEANINGS_ of the words. Let's look at the pros and cons. Why a language should not be case-sensitive: o People use |COUNT| and |count| to mean the same thing, so the compiler ought to do the same. o People will often declare SendChar and later type Sendchar, and it's painful to have to fix the error messages that a case-sensitive compiler will generate. Why languages should be case-sensitive: o People may use |COUNT| and |count| to mean the same thing, but mathematicians don't. In mathematical expressions it's very useful to use case distinctions for related entities. For example, Consider a graph G(V,E) for each vertex v in V do find an edge e in E such that e is incident on v ... Since programming languages are meant for use by technical people, and since computer programming and mathematics are so intimately related, it pays to let computer programmers use the same tools that mathematicians do. Not only should programming languages be case-sensitive, but they should allow the use of subscripts, superscripts, and Greek letters too, to make the notation more powerful and more intuitive. Right now we have to go through some trouble to compact mathematical notation to a verbose format just because the computer's character set is so inadequate. o If I declare |COUNT| and |SendChar| but use |count| and |Sendchar| later, there is a good possibility that I did so in error. After all, if I said |COUNT|, it was for a reason (why else would I have gone to the trouble of pressing my shift key?). So if I say |count| or |Sendchar| later the compiler ought to point out the discrepency. So what's the ideal compromise? 1. Keep languages case-sensitive. 2. Declare and use identifiers the same way everywhere, and don't use both xY and Xy to refer to the same identifier. 3. (Here's the new idea) Change the compiler (or lint) to accept an optional switch that will warn you any time you declare two identifiers that match except for case. This will help you avoid having both x and X in the same program if you *want* to avoid this, but it won't prevent you from using a mathematical convention that deliberately uses case to denote a similarity. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
cowan@marob.MASA.COM (John Cowan) (04/23/89)
In article <12481@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive, >as YOU CAn noW see" has a different _MEANING_ from "Because people are >case sensitive, as you can now see?" The fact is that most people are >_NOT_ case sensitive with respect to the _MEANINGS_ of the words. So, >computer languages probably shouldn't let case effect the meaning either. Well, sometimes. DEC is a computer company, but "Dec" is an abbreviation for December (credit: >Programming Pearls<); "Polish" and "polish" are actually pronounced differently, as well as having different meanings (credit: The Black Widowers); "Billy" and "BillY" are probably distinct e-mail names. NASA would look pretty odd as nasa, too. My personal feeling, for what it's worth, is that ALL UPPER CASE words should be distinct from all-lower- case words and MiXeD-CaSE-wORDs. In this scheme "foo" and "Foo" and "FoO" mean "foo", but "FOO" means "FOO" and is distinct from the others.
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/23/89)
In article <1126@ptolemy.arc.nasa.gov> raymond@ptolemy.UUCP (Eric A. Raymond) writes: -In article <10088@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: ->> Why is C case-sensitive? ->It makes programs considerably more readable, and expands the available ->name space considerably. -I think you confuse the ability to use both upper and lower case and -the concpet of whether or not upper case characters are unique from -lower case. (Translation: You can use upper and lower case in a -non-case sensitive language. Hence by your metric, they are both -readable.) No, not having different cases map onto the same object DOES make the code more readable. Otherwise you would have to constantly be mentally mapping what you were reading into monocase, in effect.
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/23/89)
In article <12480@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >But, I _don't_ like it that way. Ask any literate human whether "Tree" >means something different than "tree" and you'll find out that most humans >aren't case sensitive most of the time. You might have trouble finding literate humans these days. Is "Pooh" different from "pooh"? Silly bear.
rob@raksha.eng.ohio-state.edu (Rob Carriere) (04/23/89)
In article <12481@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <17037@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): >> BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see. >Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive, >as YOU CAn noW see" has a different _MEANING_ from "Because people are >case sensitive, as you can now see?" The fact is that most people are >_NOT_ case sensitive with respect to the _MEANINGS_ of the words. So, >computer languages probably shouldn't let case effect the meaning either. Can I give you an arbitrary math text (linear analysis will do just fine) with all the formulas lowercased and then watch and cackle hideously while you try to parse it? Same deal for just about any physics/engineering/etc text. I *like* it that my float **A and float *a are two different objects (and no, neither I nor anybody else who knows enough to make sense of the algorithm is in the slightest danger of confusion here -- it's all a matter of what you've been trained to cue on). And from the other side of the bistable multivibrator, since there are people who like this idea, since people who don't can just not use it, and since C has a spirit of live and let live, why should it not be case sensitive? Is it hurting you? SR
campbell@redsox.UUCP (Larry Campbell) (04/23/89)
In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes:
-
- Why is C case-sensitive?
Why not?
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146john@frog.UUCP (John Woods) (04/24/89)
In article <12481@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > From article <17037@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > > In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu > >> Why is C case-sensitive? > > BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see. > The fact is that most people are > _NOT_ case sensitive with respect to the _MEANINGS_ of the words. In German, "Brocken" is a piece, a lump, a morsel. "brocken" is a verb used as in the phrase "Brot in die Suppe brocken", meaning to break bread. German is case sensitive. (This example is a bit contrived, especially since "brocken" seems so limited in application. There are some less contrived examples in German (which I could neither remember nor find in my handy dictionary)). -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
tps@chem.ucsd.edu (Tom Stockfisch) (04/24/89)
In article <1126@ptolemy.arc.nasa.gov> raymond@ptolemy.UUCP (Eric A. Raymond) writes: >In article <10088@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>> Why is C case-sensitive? >>It makes programs considerably more readable, and expands the available >>name space considerably. >I agree that they improve your namespace, but not in any usable way. >(Sort of like the big gear/little gear combinations on a bike. You >can use them, but it's not a good idea.) Although its debatable, I >feel its bad style to use the same name (in diffrent cases) for >different purposes within a program. I try to avoid it, but I succumbed to temptation after reading C++ code. In C++ a struct tag name is also used as the name of a constructor for that struct. In C I always use upper case for types and (mostly) lower case for functions. I used to use lower case for types until I ran into a pcc bug in which inner-scope auto variable names collide with typedef names. Anyway, I now use the lower case version of a struct name as the name of the constructor of the struct. e.g., typedef struct NODE { char *name; struct NODE *lchild; struct NODE *rchild; } NODE; NODE * node(name) char *name; { NODE *result = malloc( sizeof(NODE) ); result->name = strsave(name); result->lchild = result->rchild = NULL; return result; } Note that I overload NODE as the structure tag and typedef name. This also is similar to the way C++ does things. -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu
peter@ficc.uu.net (Peter da Silva) (04/24/89)
In article <1126@ptolemy.arc.nasa.gov>, raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) writes: > I agree that they improve your namespace, but not in any usable way. > (Sort of like the big gear/little gear combinations on a bike. You > can use them, but it's not a good idea.) Although its debatable, I > feel its bad style to use the same name (in diffrent cases) for > different purposes within a program. You mean this is evil and rude: BOOL framistan(file) char *file; { FILE *fp; if(!(fp = fopen(file, "r"))) return FALSE; ... How about this: #define Strlen(s) (s?strlen(s):0) How about this: : LOOP ?COMPILE 3 ?MATCH COMPILE loop HERE - HERE ! ; IMMEDIATE How about homonyms? BOOL boule(fyle) char *fyle; { FILE *fp; if(!(fp = fopen(fyle, "r"))) return FALSE; ... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (04/24/89)
In article <12480@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > But, I _don't_ like it that way. Ask any literate human whether "Tree" > means something different than "tree" and you'll find out that most humans > aren't case sensitive most of the time. How about Nice and nice? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
Tim_CDC_Roberts@cup.portal.com (04/24/89)
>>> Why is C case-sensitive? >> BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see. > The fact is that most people are _NOT_ case sensitive with respect to > the _MEANINGS_ of the words. So, i was reading a book recently which covered this topic from a linguistics point of view. the book rhetorically asked if the reader could come up with any reason why the first letter of a sentence should be capitalized. when one comes right down to it, there is no good reason; you already have the period to visually terminate the previous sentence. so let's establish a new standard right now. from this point forward, the only allowable usage of capital letters shall be for EMPHASIS. this will permit emphasis to be rendered on devices which do not support underlining. once underlining is universally supporte on all media and all devices, we can eliminate capital letters altogether, and think of something else to do with 26 entries in the ascii table (smiley faces?). :-) Tim_CDC_Roberts@cup.portal.com | Control Data... ...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you.
jlg@lanl.gov (Jim Giles) (04/25/89)
> No, not having different cases map onto the same object DOES make > the code more readable. Otherwise you would have to constantly be > mentally mapping what you were reading into monocase, in effect. Most people DO mentally mapp int monocase when reading. Otherwise, I would haver to conclude that the word "DOES" is your statement is intended to mean something other than "does". In fact these are perfect examples of why a programming language should NOT be case sensitive. It allows better code readibility by allowing the programmer to EMPHASIZE parts of the code.
jlg@lanl.gov (Jim Giles) (04/25/89)
From article <2006@quanta.eng.ohio-state.edu>, by rob@raksha.eng.ohio-state.edu (Rob Carriere): > And from the other side of the bistable multivibrator, since there are > people who like this idea, since people who don't can just not use it, > and since C has a spirit of live and let live, why should it not be > case sensitive? Is it hurting you? It hurts me in two ways: 1) My job often requires me to work-on, debug, or rewrite other people's code. If the other person distinguishes "myvar" from "myVar" and several similar cases, this causes considerable heartburn. 2) Since C distinguishes case, I can't use it to help the readability of code by EMPHASIZING parts that I consider important. Fortunately, for both these cases, C has yet to become a really common language in the big computer environment. Even UNIX based supers mostly use Fortran-like languages for production.
jlg@lanl.gov (Jim Giles) (04/25/89)
From article <6899@bsu-cs.bsu.edu>, by dhesi@bsu-cs.bsu.edu (Rahul Dhesi): > [...] > o People may use |COUNT| and |count| to mean the same thing, but > mathematicians don't. In mathematical expressions it's very useful > to use case distinctions for related entities. For example, > Consider a graph G(V,E) > for each vertex v in V do > find an edge e in E such that e is incident on v > ... Math texts also tend to use one character identifiers for all objects under consideration. I don't suppose you also recommend limiting identifiers to one character?!? Programming is a fundamentally different process from writing math texts. There is no a_priori reason for one to resemble the other. Indeed, I have argued before that the syntax and semantics of arithmetical operators in programming languages _should_ resemble those use in standard math as much as possible. However, I come down on the opposite side of the issue on case sensitivity. My opinion: use multicharacter identifiers and _don't_ distinguish case. So in a programming language: type vertex... ! type - what you just called "V" vertex:: v1,v2,... !variables of type vertex > So what's the ideal compromise? > > 1. Keep languages case-sensitive. -- better yet, make case sensitivity optional. > [...] > 3. (Here's the new idea) Change the compiler (or lint) to accept > an optional switch that will warn you any time you declare two > identifiers that match except for case. This will help you avoid > having both x and X in the same program if you *want* to avoid > this, but it won't prevent you from using a mathematical > convention that deliberately uses case to denote a similarity. Better yet, make declaration of identifiers which differ only in case strictly illegal. Well, I guess it HAS to be just a warning for C to be backward compatible. Still -- a NEW language could avoid these mistakes. One last point. I have a color computer a home. To me, having a case sensitive language is as bad as having a _color_ sensitive one. Can you imagine?!? Consider a program with 512 different variables, all spelled "a". How would _YOU_ like to try to debug such a monster?
bph@buengc.BU.EDU (Blair P. Houghton) (04/25/89)
In article <12480@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <2617@buengc.BU.EDU>, by bph@buengc.BU.EDU (Blair P. Houghton): >> In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: >> 2. Huminz iz not cumpooterz. We like it that way, and we make the >> silly microchips do what WE ask. [...] > >But, I _don't_ like it that way. Ask any literate human whether "Tree" >means something different than "tree" and you'll find out that most humans >aren't case sensitive most of the time. Suggestion: alias cc to run your source through 'tr [a-z] [A-Z]' then feed it to '/bin/cc'. _You_ can decide what to do about options and the ordering thereof. --Blair "Besides, in all of my programs I always have variables named If, foR, and siZeof... :-)"
ddb@ns.network.com (David Dyer-Bennet) (04/25/89)
In article <10088@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: :In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes: :> Why is C case-sensitive? : :It makes programs considerably more readable, and expands the available :name space considerably. : :Is there some reason C should NOT be case sensitive? Well, I've seen quite a few bugs that were finally determined to be caused by programmers looking at code with identifiers with the same spelling but different casing, and thinking they were the same. I've found I got over that MOST of the time, and remember to check for it the rest of the time; but it means that when "thinking c" I have to think differently than when I'm doing most other reading tasks, which makes things epsilon much harder. It also enforces rules about casing of identifiers, so the same identifier ALWAYS looks the same, which is clearly good. How DO people feel about identifiers differing only in casing? Is this ok? To be COMPLETELY avoided? To be avoided except in a very few well-understood conventional cases? -- David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300
ddb@ns.network.com (David Dyer-Bennet) (04/25/89)
In article <17037@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: :In article <13159@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu :(Jeffrey Kuskin) writes: :>A "I was just wondering" question: :> :> Why is C case-sensitive? : :BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see. It's not so clear to me (though that's certainly a cogent example). I recognize the word "It's" at the beginning of my first sentence as just the same as the word "it's" in the middle of some sentence somewhere without any problem (after 12 years or so of concentrated training in school, that is). I think people are pretty thoroughly trained to NOT be case sensitive at the individual word level, and that your example is hard to read because it violates our training to use casing as part of punctuation. Making the rules of c casing in conflict with the rules of English casing (which I percieve them to be) was probably a bad idea, unless there are large benefits somewhere. I've certainly seen a lot of "casing" bugs. -- David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300
ddb@ns.network.com (David Dyer-Bennet) (04/25/89)
In article <10095@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
:No, not having different cases map onto the same object DOES make
:the code more readable. Otherwise you would have to constantly be
:mentally mapping what you were reading into monocase, in effect.
Which we've been trained to do by 12 years or so of schooling. I still
think it's a bad idea to fight it.
--
David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com
or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300ddb@ns.network.com (David Dyer-Bennet) (04/25/89)
In article <621@marob.MASA.COM> cowan@marob.masa.com (John Cowan) writes:
:Well, sometimes. DEC is a computer company, but "Dec" is an abbreviation
:for December (credit: >Programming Pearls<);
I see Dec and dec for the computer company all the time. And I generally
use and often see DEC for the month. The context provides more clues than
the casing does.
:"Billy" and "BillY" are probably distinct e-mail names.
Probably, but this is outside the range of normal English usage and back
into computer conventions.
:NASA would look pretty odd as nasa, too.
I see the lower-case version on the net all the time, and it's never confused
me or even slowed me down. In this case, there isn't another common term
that differs only in the formally-correct casing, so there's no ambiguity
to resolve.
I continue to believe that a trained English reader is essentially a
monocase device. The casing rules that exist mostly don't serve to
disambiguate otherwise identical terms, and when they do they are mostly
not followed; yet people can read the stuff anyway.
--
David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com
or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300ddb@ns.network.com (David Dyer-Bennet) (04/25/89)
In article <2006@quanta.eng.ohio-state.edu> rob@raksha.eng.ohio-state.edu (Rob Carriere) writes:
:And from the other side of the bistable multivibrator, since there are
:people who like this idea, since people who don't can just not use it,
:and since C has a spirit of live and let live, why should it not be
:case sensitive? Is it hurting you?
Just a reminder -- for portable code, externals should still be limited
to 6 characters monocase.
--
David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com
or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) (04/25/89)
In article <12565@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > One last point. I have a color computer a home. To me, having a > case sensitive language is as bad as having a _color_ sensitive one. > Can you imagine?!? Consider a program with 512 different variables, > all spelled "a". How would _YOU_ like to try to debug such a monster? That's like an idea a friend of mine had -- scratch 'n' sniff math texts. We have 5 senses, so why not maximize the bandwidth of the human-computer interface? You could have variables like { picture of a green cow, rotten egg smell, church bell, pinprick from the keyboard }. Wayne
pjh@mccc.UUCP (Pete Holsberg) (04/25/89)
I haven't found any computer source code easy to reed. :-)
--
Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh
Mercer College CompuServe: 70240,334
1200 Old Trenton Road GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800desnoyer@Apple.COM (Peter Desnoyers) (04/25/89)
In article <12565@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >So in a programming language: > > type vertex... ! type - what you just called "V" > vertex:: v1,v2,... !variables of type vertex Actually, what he said was set V of vertex for v = set$element in V ... Peter Desnoyers
rob@raksha.eng.ohio-state.edu (Rob Carriere) (04/25/89)
In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <2006@quanta.eng.ohio-state.edu>, by rob@raksha.eng.ohio-state.edu (Rob Carriere): >> And from the other side of the bistable multivibrator, since there are >> people who like this idea, since people who don't can just not use it, >> and since C has a spirit of live and let live, why should it not be >> case sensitive? Is it hurting you? >It hurts me in two ways: >1) My job often requires me to work-on, debug, or rewrite other people's > code. If the other person distinguishes "myvar" from "myVar" and > several similar cases, this causes considerable heartburn. This is not an argument, you might as well argue that your beloved FORTRAN is at fault for letting people name their REALs a0, a1, a2 etc in order of occurence, and INTEGERs i0, i1, etc. Any reasonable namespace can be abused by inappropriate choices. Your argument would work only if you could show that *all* case-sensitive choices of variable names are bad, and we've already seen several counterexamples to that. >2) Since C distinguishes case, I can't use it to help the readability > of code by EMPHASIZING parts that I consider important. /* VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV */ foo[37]->bar.baz += 3*pi/(2.05*e/c); /* this here be IMPORTANT! */ /* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ */ SR "I never mildly exaggerate."
rob@raksha.eng.ohio-state.edu (Rob Carriere) (04/25/89)
In article <12565@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >I don't suppose you also recommend limiting >identifiers to one character?!? Limiting, never. Allowing, certainly. exp( j*2*rhat(i)*wc ) .* ( jw.^that(i) ) % this is not C, but it gets the % point across. exp( Square_root_of_minus_one*2*Estimated_relative_range(scatterer_index) .. *vector_of_measurement_frequencies_divided_by_lightspeed ) .. * ( vector_of_measurement_frequencies_multiplied_by_the_square_root_of_minus_one .. .^ estimated_scatterer_type( scatterer_index ) ) There *is* a reason most mathematicians prefer algebra over English desciptions. > Programming is a fundamentally different >process from writing math texts. There is no a_priori reason for one >to resemble the other. Quite. But if I'm programming from a math text, I'd rather be allowed to stick as closely as possible to that text's notation. I already find rhat for r-with-^ annoying; I'll positively start screaming if I have to rename half my variables to conform to someone's empty idea of a namespace. >> 1. Keep languages case-sensitive. > -- better yet, make case sensitivity optional. That, I'd happily go along with. >Better yet, make declaration of identifiers which differ only in case >strictly illegal. Well, I guess it HAS to be just a warning for C >to be backward compatible. Still -- a NEW language could avoid these >mistakes. But, it is not a mistake. At least not to quite a number of people. >One last point. I have a color computer a home. To me, having a >case sensitive language is as bad as having a _color_ sensitive one. >Can you imagine?!? Consider a program with 512 different variables, >all spelled "a". How would _YOU_ like to try to debug such a monster? I wouldn't like to have 512 variables of any ilk in consideration scope in any way, regardless of naming schemes. Me got only small skull, me KISSes all my programs (when they let me :-). I *have* debugged mathematical arguments where there were variables r, R, rho and GAMMA (looks like a rho), all blissfully different. I was happy with it. There was a system to the choice of alphabets, and same letter in different alphabets meant related quantities; it was all very intuitive. SR
afscian@violet.waterloo.edu (Anthony Scian) (04/25/89)
In article <12565@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [text deleted] >Better yet, make declaration of identifiers which differ only in case >strictly illegal. Well, I guess it HAS to be just a warning for C >to be backward compatible. Still -- a NEW language could avoid these >mistakes. What mistakes? Why should everybody accept case-insensitivity? Given a case-sensitive compiler, you can program to your heart's content in case-insenstive bliss, so what is the problem? Just pipe your source through 'tr' and map the entire alphabet to whatever case you like. (If you are feeling ambitious, write your own CPP so that there is one less filter in the pipeline) As for keywords, what is wrong with: #define IF if #define WHILE while etc. If you dictated that case-insensitivity rules, those of us that want case-sensitive compilers would be out of luck. I find it really annoying when I find case errors later rather than sooner because of case-insensitive tools. As for the `silly errors' point, we don't need more relaxation of checking when it comes to errors. We have enough lazy C trash to rid ourselves of (what? default int, default export, etc). I think you lost the important point in this thread of thought: Programmers should not overload names with case-sensitive variations on a theme. //// Anthony Scian afscian@violet.uwaterloo.ca afscian@violet.waterloo.edu //// "I can't believe the news today, I can't close my eyes and make it go away" -U2
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (04/25/89)
In article <12565@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Math texts also tend to use one character identifiers for all objects >under consideration. I don't suppose you also recommend limiting >identifiers to one character?!? There *is* a reason for mathematicians to use single-character identifiers. This is because a large fraction of mathematical expressions contain some type of product, and it's very convenient to be able to say "abc" and mean "a * b * c". Once you begin with the convention that abc is a product of three terms, it's confusing to do otherwise in the same book or journal. Most computer programs do not necessarily involve products, so it pays to give up the convenience of mathematical notation to gain clarity by using longer identifiers. But single-character identifiers *are* useful. Most loop counters are one-char identifiers. When you are evaluating a conventional mathematical expression it often pays stick to that format. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
rob@raksha.eng.ohio-state.edu (Rob Carriere) (04/25/89)
In article <1318@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes: >I continue to believe that a trained English reader is essentially a >monocase device. The casing rules that exist mostly don't serve to >disambiguate otherwise identical terms, and when they do they are mostly >not followed; yet people can read the stuff anyway. English != C A trained English reader does not a trained C programmer make, nor vice versa. SR
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/25/89)
In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Even UNIX based supers mostly use Fortran-like languages for production. Where that's true, for example perhaps LANL, I'm sure it's not because C identifiers support case distinction. It is much more likely an inertial effect. At BRL, many of the important applications that run on our Crays are written in C.
jcbst3@cisunx.UUCP (James C. Benz) (04/25/89)
In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >Fortunately, for both these cases, C has yet to become a really common >language in the big computer environment. Geez, where you been for the last ten years, Rip Van? -- Jim Benz jcbst3@unix.cis.pittsburgh.edu If a modem University of Pittsburgh answers, UCIR (412) 648-5930 hang up!
jlg@lanl.gov (Jim Giles) (04/26/89)
From article <29478@apple.Apple.COM>, by desnoyer@Apple.COM (Peter Desnoyers): > set V of vertex > for v = set$element in V > ... In that case, it _should_ have been: set vertex_set of vertex for a_vertex = set$element in vertex_set Assuming that the two statements above may be separated in the program by many lines (even pages) of other code, the "vertex_set" variable is _MUCH_ easier to read, maintain, and even to _WRITE_!
hardy@rb-dc1.UUCP (Jeff Hardy) (04/26/89)
I've heard many arguments in this discussion group that state that allowing case sensitivity is HARD. I believe that HARD is like BEAUTY and is in the eye of the beholder. What is HARD for you MAY be EASY for me and what is HARD for me MAY be EASY for you. I don't believe that Dennis designed C to be HARD. I don't believe that HARDness is an attribute of the language at all. Many people have brought out the useful fact that case sensistivity allows another means of conveying information. Why preclude that means simply because to some it is HARD. I dare say that if we prevented early on anything that is HARD, we wouldn't be where we are today. What we DO need however is the recognition that to some it is indeed HARD and as others have brought out it is our responsibility to try not to be arbitrarily HARD on others. Clear documentation should help in some degree. Perhaps well understood conventions will help also. Also, I do not necessarily map UPPERCASE to lowercase in order to understand some word. I believe that my thought processes are more mature than that. I also do not move my lips when I read. People who learn more than one language learn to think in the other languages too. They do not have to translate into their mother tongue to understand what is being said. I'm sure this can be appliled to programming languages as well. The mental translation and HARDness pass away with experience and growth. To deny ourselves the HARDness is to deny our capacity for growth. Jeesh, I'm really sorry for the sermon :-), but this did seem to border on the religious. Cheers, Jeff Hardy
zougas@me.utoronto.ca ("Athanasios(Tom) Zougas") (04/26/89)
In article <2026@quanta.eng.ohio-state.edu> rob@raksha.eng.ohio-state.edu (Rob Carriere) writes: > [...] >>> 1. Keep languages case-sensitive. >> -- better yet, make case sensitivity optional. > >That, I'd happily go along with. > Please don't make it optional. I would end up using case-sensitivity ON just in case I did want to distinguish between MyVar and MYVAR. Or in case someone else wanted to distinguish between TheirVar and THEIRVAR. KnowwhatImean? Tom. -- This is my signature: tom zougas
bill@twwells.uucp (T. William Wells) (04/26/89)
'Round and round we go...
In article <12561@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
: Most people DO mentally mapp int monocase when reading. Otherwise,
: I would haver to conclude that the word "DOES" is your statement is
: intended to mean something other than "does". In fact these are
: perfect examples of why a programming language should NOT be case
: sensitive. It allows better code readibility by allowing the programmer
: to EMPHASIZE parts of the code.
Inconsistent casing Makes the Code harder to Read. Consistent casing
is better, pretty much independetly of which style of case you use.
And if you use consistent casing, you want your compiler system to
tell you when you've goofed.
So, even if you want to use case for such purposes as emphasis, you
want case sensitivity in the language.
---
Bill { uunet | novavax } !twwells!billtainter@ihlpb.ATT.COM (Tainter) (04/26/89)
In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <2006@quanta.eng.ohio-state.edu>, by rob@raksha.eng.ohio-state.edu (Rob Carriere): >> case sensitive? Is it hurting you? >1) My job often requires me to work-on, debug, or rewrite other people's > code. If the other person distinguishes "myvar" from "myVar" and > several similar cases, this causes considerable heartburn. There is one more options. Design it into the language that case must match but that no two symbols when case ignored are allowed to be the same. I.e. case and Case is illegal! Or add it to your coding guidelines and run the code through a checker to enforce it. Any votes for this? It won't get my vote. I like using WHITE and white as distinct, one the instantiation of the other, and don't agree it makes code harder to read. As long a reasonable convention is used for why they differ in case there is little problem. Personally, I think people who do mixed case like MyVar should be shot! I can tolerate Variable but it had better be some special class of symbol (typedef, structure tag, class, etc.) > >2) Since C distinguishes case, I can't use it to help the readability > of code by EMPHASIZING parts that I consider important. A frightening prospect! This would force me to run all code I know you wrote through a filter to calm it down, which would be very messy under a change management system. What you think you know what is important to the next guy reading the code? This type of thing just distracts from general understanding of the code and context. --johnathan.a.tainter--
desnoyer@Apple.COM (Peter Desnoyers) (04/26/89)
In article <12641@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >From article <29478@apple.Apple.COM>, by desnoyer@Apple.COM (Peter Desnoyers): >> set V of vertex ... >In that case, it _should_ have been: > set vertex_set of vertex ... > >Assuming that the two statements above may be separated in the program >by many lines (even pages) of other code, the "vertex_set" variable is >_MUCH_ easier to read, maintain, and even to _WRITE_! I don't agree. If the form in which everyone learned the equation uses X, x, and z, then use those very same symbols. Which would you rather read: Area := ratio_of_diameter_to_circumference * radius_of_circle ^^2 or ___ 2 A = | | R Peter Desnoyers
jlg@lanl.gov (Jim Giles) (04/26/89)
From article <17736@cisunx.UUCP>, by jcbst3@cisunx.UUCP (James C. Benz): > In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>Fortunately, for both these cases, C has yet to become a really common >>language in the big computer environment. > > Geez, where you been for the last ten years, Rip Van? I have found that there are definitely _better_ languages in the world than C. Some, like Fortran, are only better for certain applications. Others are better than C in almost _every_ respect, like Modula2-3 or even ADA. There are, of course, derivatives of C itself that are uniformly better than C - like C++, and Objective C is better than that but not widely available yet. I usually don't switch to a language simply because it's trendy. That seems to me to be the only reason to switch to C (it also seems to be the general idea behind your: "last ten years, Rip Van?). Not even at home on my personal computer - there I prefer SmallTalk for playing with algorithms and Modula2 for programs which need to be small/fast. I have, of course, used C - I even wrote an interpreter at home for it (just to get a better feel for the language) - the more I learn about it, the less I like it. So, I say again: Fortunately C has yet to become a really common language in the big computer environment - or I would be _forced_ to use it as part of my job.
bbadger@x102c.harris-atd.com (Badger BA 64810) (04/26/89)
In article <17552@cup.portal.com> Tim_CDC_Roberts@cup.portal.com writes: [..] >so let's establish a new standard right now. from this point forward, >the only allowable usage of capital letters shall be for EMPHASIS. this >will permit emphasis to be rendered on devices which do not support >underlining. once underlining is universally supporte on all media and >all devices, we can eliminate capital letters altogether, and think of >something else to do with 26 entries in the ascii table (smiley faces?). > :-) >Tim_CDC_Roberts@cup.portal.com | Control Data... >...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you. In \TeX, it is considered more elegant to {\em emphasize} a concept with a contrast between {\rm roman} and {\it italic} fonts, rather than crudely \underline{underlining} something! (In a manuscript, underlining is used to indicate that italics are desired.) At the moment we are constrained by current character/terminal/printer/font technology to define programming languages in a linear sequence of (probably ASCII) characters. I'm not sure we're ready for the the coming graphical/visual technology explosion. As regards the theme, ``Why case-sensitivity?'' I _definitely_ prefer being able to use both upper and lower case, with a predominance of lowercase. I generally *don't* like it when an identifier is used in several different case treatments: I read ``APart'' and ``apart'' differently, so in Ada, would always write that as ``a_part'' and ``apart''. I wouldn't allow mere capitalization to serve as a word marker. Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!'' Secure Computer Products |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
jlg@lanl.gov (Jim Giles) (04/26/89)
From article <29544@apple.Apple.COM>, by desnoyer@Apple.COM (Peter Desnoyers): > I don't agree. If the form in which everyone learned the equation uses > X, x, and z, then use those very same symbols. Which would you rather > read: > Area := ratio_of_diameter_to_circumference * radius_of_circle ^^2 > or > ___ 2 > A = | | R Neither. I'd rather see: c1.area <- @pi * c1.radius^2 This has several advantages. 1) It is possible to write with my keyboard without multi-line superscripting or special character drawing. 2) Pi _should_ be a built-in constant in a programming language. Its value should be kept to the maximum (machine dependent) precision, but it should be used only to the precision required by the rest of the expression. (I think that '@' is just as good a character as any to signal intrinsic constants.) 3) This example identifies, completely and uniquely, _which_ circle is having its area computed. You might argue that the data type 'circle' should have sub-field names that are shorter (I won't argue that point). But both your examples imply only one circle in the computational universe of possibilities. This is the difference between forms that you learn and forms that you _use_. The form you learn is a template that must be filled out with specifics in actual use. Programming is a medium of _use_, not a medium of learning. It must, therefore, have not only the learned _form_, but be filled out with the specifics as well. 4) It has an _assignment_ symbol. Your example is misleading in its use of the equal sign. In a functional language, like VAL, your second example could as easily mean that you're defining 'R' instead of your probable intent to define 'A'. (Of course, ":=" looks nothing like a left-arrow and should be avoided for assignment in a programming language design.)
jeenglis@castor.usc.edu (Joe English) (04/26/89)
jlg@lanl.gov (Jim Giles) writes: > >2) Since C distinguishes case, I can't use it to help the readability > of code by EMPHASIZING parts that I consider important. I don't get it... c = read(fd,buffer,count); /* read stuff from file */ c = READ(fd,buffer,count); /* be SURE to read stuff from file. Don't write or lseek, READ. */ c = read(FD,buffer,count); /* read from file FD. Not some other file descriptor, FD. */ c = read(fd,BUFFER,count); /* read stuff into BUFFER, and not somewhere else. */ I still don't get it. --Joe English jeenglis@nunki.usc.edu
pat@mslanpar (Pat R. Calhoun) (04/26/89)
In article <12480@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > But, I _don't_ like it that way. Ask any literate human whether "Tree" > means something different than "tree" and you'll find out that most humans > aren't case sensitive most of the time. Then why do you use _I_ and not _i_?? -- "The statements above does not necessarily reflect the views of the writer, the President of the United States, or the cleaning staff." _^_ ||| Pat "King of the Trenches" Calhoun <o o> | Technical Support Group, Lanpar Technologies /\/\/\/\/\ UUCP: ...!attcan!nebulus!tslanpar!mslanpar DISCLAIMER: "Read the DAMN manual, I don't need this SHIT!!"
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/26/89)
In article <2027@quanta.eng.ohio-state.edu> rob@raksha.eng.ohio-state.edu (Rob Carriere) writes: >English != C Congratulations. I don't know where the utterly fantastic notion that natural language should serve as a guide for a programming language came from. They have different goals, different structure, different methods, and different "clientele". Almost the only thing they have in common is the word "language", but the only common concept in these two usages is, essentially, "mode of expression", which is way too general to provide detailed guidance. If people approach programming the same way that they approach essay writing, no wonder they have problems. But in that case it's not the fault of the programming language.
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/26/89)
In article <12666@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >[C] - the more I learn about it, the less I like it. You're certainly entitled to your opinions, if you've formed them as the result of objective consideration of the facts available to you. However, if you don't like C, you're doing the readers of this newsgroup a disservice by complaining about it, just as it does nobody any good for VMS advocates to argue that UNIX is awful in the UNIX newsgroups. Constructive suggestions about ways to work around what you perceive to be deficiencies in C would be helpful. If it weren't too late now, suggestions about ways to improve the language would have been useful too. (I don't recall seeing yours in the mountain we had to wade through before or during the public reviews of the proposed C standard.) But if you're not trying to be helpful, then please keep quiet -- the signal-to-noise ratio of this newsgroup is low enough already.
mcdonald@uxe.cso.uiuc.edu (04/26/89)
>A "I was just wondering" question: > Why is C case-sensitive? Who cares? Who cares? Who cares? One would be able to write exactly the same programs in C whether it began life as case sensitive or not! (With the possible exception that they might break if you had two global varibles differing only in case! You see, C really IS case insensitive for certain things.)
jlg@lanl.gov (Jim Giles) (04/27/89)
From article <10321@ihlpb.ATT.COM>, by tainter@ihlpb.ATT.COM (Tainter): > [...] As long a reasonable > convention is used for why they differ in case there is little problem. > > Personally, I think people who do mixed case like MyVar should be shot! Unfortunately, irrational conventions often occur. And, since shooting the programmer is illegal (and doesn't solve the immediate problem anyway), it would have been better if the feature had never been allowed. (By the way, if I _NEVER_ had to deal with anyone's code but my own, I too would probably support case sensitivity. But, I do so I don't.) >> of code by EMPHASIZING parts that I consider important. > > A frightening prospect! [...] > [...] What you think you > know what is important to the next guy reading the code? [...] As often as not, I'm the next person reading the code. I at least know what I think is important. I any case, the fix for others is obvious and easy, translate everything to lowercase (as you pointed out). If the fix for mixed case variables in C were as easy, I would have no objection to them.
suitti@haddock.ima.isc.com (Stephen Uitti) (04/27/89)
In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > ...case sensitivity discussion... >Fortunately, for both these cases, C has yet to become a really common >language in the big computer environment. Even UNIX based supers mostly >use Fortran-like languages for production. One may read this as "common usage is x, therefore x is better". Supers are becoming UNIX based for the same reason that lots of new machines are UNIX based - because people can do it. No one wants to implement a new OS (other than maybe Big Blue). People are writting in Fortran, COBOL, or whatever, because that is what they know. (Same reason - they can). This has little to do with what makes a maintainable system. I've maintained Fortran code. It sucks. Modularity is poor. Global variables are everywhere. The common statements sometimes don't match. Some programmer wanted to save an assignment by switching two names. Pass-By-Name-Only causes all sorts of strange side effects. Even the straight forward loops have labels and goto's. I've maintained BASIC code. No parameter passing. Everything is global. One and two character variable names. Sigh. I'm not going to say "C is best", even if this is comp.lang.c. Still, i have seen vectorizing C compilers on Supers. I've seen an application get over 150 MFLOPS with it. I've also seen scientific types who have programmed in Fortran for the last 30 years use it. I think the only reason that they switched from assembler is that the assembler they learned first disappeared with the machine(s) they first used. It took years for them to switch to the "new fangled" Fortran (around 1962?). If the only well supported scientific language for a supercomputer was Postscript, you'd find people using it. You'd even find people who like it. Stephen.
suitti@haddock.ima.isc.com (Stephen Uitti) (04/27/89)
>> In mathematical expressions it's very useful >> to use case distinctions for related entities. For example, >> Consider a graph G(V,E) >> for each vertex v in V do >> find an edge e in E such that e is incident on v >> ... > >Math texts also tend to use one character identifiers for all objects >under consideration... True story. Two physics profs are standing at a blackboard. There is an equation on the board, something like 2 f(y)ab sin(x) The one prof is heard to say, "yes, I see f, x, y, a and b, but what are s, i, and the n function?". >One last point. I have a color computer a home. To me, having a >case sensitive language is as bad as having a _color_ sensitive one. >Can you imagine?!? Consider a program with 512 different variables, >all spelled "a". How would _YOU_ like to try to debug such a monster? And your color printer only prints 16 different colors. What is the ASCII value of a red 'a' anyway? Stephen.
jlg@lanl.gov (Jim Giles) (04/27/89)
From article <10122@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn): > However, if you don't like C, you're doing the readers of this newsgroup > a disservice by complaining about it, just as it does nobody any good > for VMS advocates to argue that UNIX is awful in the UNIX newsgroups. I agree entirely with this assessment. In fact, I was going to recommend that this thread of the discussion be moved to comp.lang.misc where it is at least plausible that program language design features can be discussed with a eye toward the design of new languages. Examination of the percieved mistakes in C has a valid application in this context. > [...] If it weren't too late now, > suggestions about ways to improve the language would have been useful > too. (I don't recall seeing yours in the mountain we had to wade > through before or during the public reviews of the proposed C standard.) I read the draft standard cover-to-cover. I disqualified myself on making comment, however, because most of my objections to the language involve features that most people consider to be the 'heart' of C. A suggesion that intrinsic operators with side-effects should not be implemented would hardly have been accepted as serious criticism by a committee standardizing C, for example.
ddb@ns.network.com (David Dyer-Bennet) (04/27/89)
Rob@raksha.eng.ohio-state.edu (Rob Carriere) writes: > >English != C > >A trained English reader does not a trained C programmer make, nor >vice versa. Certainly not; however, both activities are performed using words and wordlike character groupings. I maintain that it is silly for the new upstart activity (programming) to establish rules that are in conflict with the rules of the old, established activity (reading). This only makes it harder to learn C programming, and causes lingering errors for years (or forever). -- David Dyer-Bennet, ddb@terrabit.fidonet.org, or ddb@ns.network.com or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb or Fidonet 1:282/341.0, (612) 721-8967 9600hst/2400/1200/300
jlg@lanl.gov (Jim Giles) (04/27/89)
From article <12801@haddock.ima.isc.com>, by suitti@haddock.ima.isc.com (Stephen Uitti): > In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >> ...case sensitivity discussion... >>Fortunately, for both these cases, C has yet to become a really common >>language in the big computer environment. Even UNIX based supers mostly >>use Fortran-like languages for production. > > One may read this as "common usage is x, therefore x is better". No, one may _not_ read what I said in this way. On UNIX, C usage is common - even to the virtual exclusion of all else. By your interpretation of what I said, you might think that I like C better on UNIX. I don't. I think C is less than optimal (or even good) in ALL environments. > I'm not going to say "C is best", even if this is comp.lang.c. > Still, i have seen vectorizing C compilers on Supers. I've seen > an application get over 150 MFLOPS with it. I just saw (within minutes ago) a Fortran benchmark getting 257 MFlops. Now, I'm not going to say "Fortran is best". In point of fact, I'm completely dissatisfied with Fortran (no array syntax, no dynamic memory, too much 'storage association'). But, I don't want to switch to C either. I don't think C is an improvement (except dynamic memory, C shares all the problems that dissatisfy me about Fortran - and it has additional problems of its own).
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/27/89)
In article <12715@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >A suggesion that intrinsic operators with side-effects should not be >implemented would hardly have been accepted as serious criticism by >a committee standardizing C, for example. Serious, perhaps. Feasible, certainly not. I agree with the move of discussions about what programming languages "should" be like (as opposed to what C actually is) to comp.lang.misc.
john@frog.UUCP (John Woods) (04/27/89)
In article <12564@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > > 2) Since C distinguishes case, I can't use it to help the readability > of code by EMPHASIZING parts that I consider important. Have you ever considered comments? They not only allow you to emphasize important sections of code, you can even explain why they are important. I understand that this facility is even available in FORTRAN, but fortunately if you do object to it, you need only remove the cards with a C in column one. Should be easy enough to rewire the card sorter to do that automatically for you! :-) -- John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
chris@mimsy.UUCP (Chris Torek) (04/27/89)
[I do not know why, but I cannot resist...] >In some article whose referent was deleted by faulty news software, >Rob@raksha.eng.ohio-state.edu (Rob Carriere) writes: >>A trained English reader does not a trained C programmer make, nor >>vice versa. In article <1325@ns.network.com> ddb@ns.network.com (David Dyer-Bennet) writes: >Certainly not; however, both activities are performed using words and >wordlike character groupings. I maintain that it is silly for the >new upstart activity (programming) to establish rules that are in >conflict with the rules of the old, established activity (reading). >This only makes it harder to learn C programming, and causes lingering >errors for years (or forever). Clearly, then, if we are to make the language case-insensitive, it should also be insensitive to alternative spellings for the same word. For instance: f() { int recognized; ... recognised = token_is_ok(); After all, these mean the same thing. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dg@lakart.UUCP (David Goodenough) (04/27/89)
suitti@haddock.ima.isc.com (Stephen Uitti) sez: > And your color printer only prints 16 different colors. What is the > ASCII value of a red 'a' anyway? Hummmmm - I didn't know we had a mapping from cryllic to ASCII :-) -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
daveh@marob.MASA.COM (Dave Hammond) (04/28/89)
Doesn't ANYONE care that the daily traffic in lang.c has *doubled* in the past week, all for a pointless(%) discussion which no longer has any bearing on the C langauge? [yea, I know -- I can just hit 'n' ... 40 times a day] -- % pointless, in that the C standard couldn't possibly be altered now. Even if it could, mandating case-sensitivity would break every program in existance. -- Dave Hammond daveh@marob.masa.com
trent@unix.SRI.COM (Ray Trent) (04/29/89)
In the referenced article, jlg@lanl.gov (Jim Giles) writes: >>> Why is C case-sensitive? >> BecAUSe peopLE arE CaSE senSITive, as YOU CAn noW see. > >Ah, but do you intend to imply that "BecAUSe peopLE arE CaSE senSITive, >as YOU CAn noW see" has a different _MEANING_ from "Because people are >case sensitive, as you can now see?" The fact is that most people are I would claim that. Your article damns your argument, in this case :-), because I claim (with some certainty) that you would never had replied in this way if the previous author had written "Because people are case sensitive, as you can now see." The implication of this assertion is that some additional information *was* conveyed by the previous author's use of non-standard capitalization. -- "When you're down, it's a long way up When you're up, it's a long way down It's all the same thing And it's no new tale to tell" ../ray\..
nevin1@ihlpb.ATT.COM (Liber) (04/29/89)
In article <12564@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >1) My job often requires me to work-on, debug, or rewrite other people's > code. If the other person distinguishes "myvar" from "myVar" and > several similar cases, this causes considerable heartburn. It would cause me heartburn, too. This is an ABUSE of case sensitivity; case conventions also have to be followed. And, as you so eloquently point out in the next sentence, case insensitivity can also be abused! Don't blame the language; blame the programmers! >2) Since C distinguishes case, I can't use it to help the readability > of code by EMPHASIZING parts that I consider important. Blech!! I would NEVER change case on a variable name, even in a case-insensitive language. This leads to many more problems (it IS harder to follow because you mentally have to do some preprocessing, you can get unintended aliases, etc.) than it is worth. Maybe you would prefer your alphabet to have two symbols: "0" and "1"? :-) -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (312) 979-4751 IH 4F-410 ' ) ) "I will not be pushed, filed, stamped, indexed, / / _ , __o ____ briefed, debriefed or numbered! My life is my own!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
billd@celerity.UUCP (Bill Davidson) (04/29/89)
In article <1319@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes: >Just a reminder -- for portable code, externals should still be limited >to 6 characters monocase. If there's any justice in the world, OS's that cause this restriction will die a well desrved death soon. Bill Davidson ...!ucsd!celerity!billd
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/01/89)
In article <232@celit.UUCP> billd@celerity (Bill Davidson) writes: >In article <1319@ns.network.com> ddb@ns.UUCP (David Dyer-Bennet) writes: >>Just a reminder -- for portable code, externals should still be limited >>to 6 characters monocase. >If there's any justice in the world, OS's that cause this restriction >will die a well desrved death soon. I wouldn't argue that there's much justice in today's world, but anyway you don't have to limit your externals as cited. If you're coding for maximal portability, you have to be aware of the mapping that may occur and avoid using external names that might collide under such mapping, but you don't have to do the mapping yourself. If it's going to occur, the compiler, assembler, and/or linker will do it for you. If you're coding for less than full portability, for example strictly for a POSIX environment, there are much more liberal guarantees for external identifiers.