ignatz@aicchi.UUCP (Ihnat) (05/17/85)
All right, people... If you insist on making 'C' programs look like COBOL by using 32,767 character names, the *very* least you can do is make the damn things unique in the first 7 characters, OK? This long-name-chauvinism is annoying enough in sources posted to net.sources, but now I'm running into it in sources for paying business purposes, and it's, frankly, intolerable. One of the greatest assets of 'C' is its great degree of portability. But there are tens of thousands of binary-license 'C' compilers out there. These people don't have the freedom to modify their compiler; and when they pay some outside joker to write something in 'C', and he/she writes it with 15-character variable names that are only unique in the last 2 characters because "compilers should be able to handle it, and it's conceptually desirable", or some such drivel, they can't regenerate it on their system. What then? Yep. They pay twice, to have someone else fix the code. C'mon; all 'C' compilers that I know of will accept very long variables, just chopping off the excess characters. I'll read your bloody Dickensian novels, if I must, but fer Crissakes, at least do it in a portable, intelligent, and reasonable manner. (No, don't tell me that I can write or get a preprocessor program to mung the source--this makes debugging and understandability even more of a joke than it already is.) In High Dudgeon, -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz
geoff@boulder.UUCP (Geoffrey M. Clemm) (05/20/85)
The tone of this response is intended to match that of the original posting. If you dislike rude and mindless behaviour, 'j' this message. In article <aicchi.476> ignatz@aicchi.UUCP (Ihnat) writes: >All right, people... > >If you insist on making 'C' programs look like COBOL by using >32,767 character names, the *very* least you can do is make the >damn things unique in the first 7 characters, OK? "Fer Crissakes", this "damn" "drivel" from that "intolerable" "joker" Ihnat is "bloody" "annoying". (All quoted words verbatim from Ihnat's posting). Well, my compiler will only take single character identifiers, and any program that uses longer ones is being verbose and non-portable (ask any Basic programmer from the 1960's). >(No, don't tell me that I can write or get a >preprocessor program to mung the source--this makes debugging and >understandability even more of a joke than it already is.) Oh, you are concerned about "understandability". And you can't see the point in having names longer than 7 characters ? Well, you see there is a tradeoff between portability and understandability, and some of us are more concerned about understandability than porting to your compiler.
aeb@mcvax.UUCP (Andries Brouwer) (05/20/85)
In article <476@aicchi.UUCP> ignatz@aicchi.UUCP (Ihnat) writes: > >If you insist on making 'C' programs look like COBOL by using >32,767 character names, the *very* least you can do is make the >damn things unique in the first 7 characters, OK? > >This long-name-chauvinism is annoying enough in sources posted to >net.sources, but now I'm running into it in sources for paying business >purposes, and it's, frankly, intolerable. > >One of the greatest assets of 'C' is its great degree of portability. >But there are tens of thousands of binary-license 'C' compilers out there. >These people don't have the freedom to modify their compiler; and when >they pay some outside joker to write something in 'C', and he/she writes >it with 15-character variable names that are only unique in the last 2 >characters because "compilers should be able to handle it, and it's >conceptually desirable", or some such drivel, they can't regenerate it >on their system. What then? Yep. They pay twice, to have someone else >fix the code. Yes, that is what happens if you meet such a program once a year. But now suppose you got such a program every week. Wouldnt you instead buy a better compiler/loader? It is reasonable to expect that new compilers accept programs that were written long ago, but it would prevent all progress if one required that new programs not use any features that were introduced into the language in the past ten years. ("My compiler cannot handle two-dimensional arrays of structures"; "mine barfs on unsigned bit fields"; "mine doesnt like functions returning structures"; "mine dumps core on long int cases in a switch"; "mine cannot evaluate arithmetic expresssions with more than five levels of parentheses"; "mine cannot initialize structs"; "mine doesnt translate register char's correctly"; "my preprocessor produces garbage when identifiers of more than 16 chars are #defined"; "my C compiler handles 10 char identifiers, but my loader retains only the first 6 symbols" - etc. [These are actual complaints.] Do you have a crappy preprocessor/compiler/loader? Too bad. You may choose between buying a better compiler and wasting some of your time each time you have to port something to your machine.) The more programs are written in rich dialects of C the stronger the pressure will be on compiler writers to produce compilers that perform better than minimally. Quite a different point is that identifiers may be mechanically generated in some systematic and meaningful way, and in such cases it might be a pain to distort the identifier generation scheme in such a way that no identifiers longer than 16? 8? 7? 6? symbols are generated.
guy@anasazi.UUCP (Guy Finney) (05/20/85)
I have to agree. The case in point here is the highly acclaimed GNU Emacs.
We got it shortly after it was announced over the net that it was
available. We had been warned it would be somewhat 4.2-specific, but
figured it wouldn't be too long a job to convert to Sys V (has anyone
got it on Sys V - we'd like to hear from you). Surprise! #defines,
variable names, etc not unique within even 20 characters. We're one of
the poor binary licensees alluded to by the author, and called the person
who gave us GNU Emacs for help. He said something like "Oops, well, we think
self-documenting code is such a good thing that we traded portability
for it. Can I interest you in a nice convert-o-matic program?". Great.
This guy may be a whiz-bang software architect, but he doesn't seem to
understand maintainability at all. We got the convert-o-matic program
(I think it's called clash), but then updates began coming out to GNU
Emacs, and the amount of time it took to port the original plus the
updates...well, we gave up trying. We just threw away GNU Emacs
entirely. In contrast, the folks who do Kermit seem to have
portability as their primary consideration. C-Kermit took something
like an hour to get up and running without portability bugs,
and that includes compile time. They've got the right attitude.
--
Guy Finney
{decvax|ihnp4|hao}!noao!terak!anasazi!guyfaustus@ucbcad.UUCP (Wayne A. Christopher) (05/21/85)
> If you insist on making 'C' programs look like COBOL by using > 32,767 character names, the *very* least you can do is make the > damn things unique in the first 7 characters, OK? If you're so concerned about those people who have dumb compilers, why don't you write a program to systematically rename variables to make them 7 character unique? It couldn't be that tough, and then those of us who have the brains to use decent C compilers don't have suffer having variable names that we don't want. If it were the first 10 or 12 characters then it wouldn't so bad, but 7 characters is too little to have to worry about. Wayne
jer@peora.UUCP (J. Eric Roskos) (05/22/85)
While I don't read net-lang.c presently, and REFUSE to participate in net.unix-warriors ... uh... wizards, this discussion has leaked into net.sources. The posting 668@mcvax is an example of the "All the World's a VAX" attitude which was discussed recently in the Usenix paper "Can't Happen, or, /* NOTREACHED */, or, Real Programs Dump Core," by Ian Darwin and Geoff Collyer. This unfortunate attitude dogmatically assumes that one's present machine is the be-all-and-end-all, and that thus whatever exists on one's present machine should therefore be what exists on everyone else's system, and if it isn't, well, they are just behind the times and need to catch up. But this attitude is myopic and ridiculous. Authors of programs posted to net.sources should not be in the business of trying to force everyone else to adopt whatever extensions to the language exist on their particular machine. That's what's basically wrong with the statement: > But now suppose you got such a program every week. Wouldnt you > instead buy a better compiler/loader? It assumes that a better compiler/loader exists for their machine, that one can afford to purchase such a compiler/loader, or that one can influence the purchase of a new compiler/loader just because some public-domain programs show up that require it. The list the author then gives indeed documents a number of things people should watch out for in writing portable programs. Unfortunately, the author concludes that one SHOULD use exactly these, in order to bludgeon people into adopting the new extensions. This is unreasonable. You have to accept the fact that many users don't yet have these features; maybe they are just a small business, or a small college with a yearly equipment budget of $7000 per year, or maybe just some students who have to make do with whatever machine their university supplied them. You can't really force these people to change in the short run. Either you have to have the courtesy to use wisdom in programming, or have your program not be used by them. But the philosophy expressed in the article I am commenting on is roughly equivalent to the statement I drive a Honda Accord, which as a 3-barrel carburetor. I think we should quit making anything but 3-barrel carburetors, because they are the state-of-the art and if we do that, soon all car manufacturers will use them too. It's simply an issue of compatibility. Unless you want to make your users suffer unnecessarily, you should introduce new changes gradually, and wait for the old ones to die out gracefully, rather than forcing new features on the user. If the new features are truly worthwhile, they will, in time, find their way into all compilers. This is a hard problem to deal with, but it is simply the reality of practical programming in the real world. ---- [I guess a disclaimer is required here. The above is my opinion, and does not necessarily reflect that of PE. Actually, PE's compilers support all the new features the author listed, to my knowledge. My comments are based on the fact that I recently attended a college which had an old Edition 7 system, with an "old" compiler, simply because their budget was not adequate to go purchasing new compilers until the features of them were well established and standardized; which, in their case, will probably be when they buy a new machine.] -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 EKE. Jngpu bhg sbe gur pnef.
karsh@geowhiz.UUCP (Bruce Karsh) (05/24/85)
>It's simply an issue of compatibility. Unless you want to make your users >suffer unnecessarily, you should introduce new changes gradually, and wait >for the old ones to die out gracefully, rather than forcing new features >on the user. I agree with this statement, but I don't know how long I have to wait for the old compilers to go away. Does somebody want to make a guide- line for this? For example, is it reasonable to use a new feature that is only 2 years old? 4 years old? 8 years old? 16 years old? How long do we have to wait? I guess I think 2 years old is enough. Maybe 3 if you want to be super cautious. But I don't think we should make people's old software hold back progress any longer than that. -- Bruce Karsh | U. Wisc. Dept. Geology and Geophysics | 1215 W Dayton, Madison, WI 53706 | This space for rent. (608) 262-1697 | {ihnp4,seismo}!uwvax!geowhiz!karsh |
barmar@mit-eddie.UUCP (Barry Margolin) (05/24/85)
In article <964@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >If the new features are truly worthwhile, they will, in time, >find their way into all compilers. This is a hard problem to deal with, >but it is simply the reality of practical programming in the real world. But if I (or my school, or my company) choose to purchase a featureful compiler, and I end up paying more than others in order to get a compiler that meets the full standard, why should I let these features go to waste because not everyone has a correctly working compiler? If I pay for a complete implementation of the language I shouldn't have to wait for everyone else to catch up before I can use all the features{ Of course, the issue is whether you are writing programs for yourself (or your organization) or for sharing with as many others as possible. If the latter you must be careful and aim for the common denominator. If you don't care about complete portability, then you can use the features that you paid extra for. There is another issue in variable name usage that is probably less controversial (although I'm sure there are people who will flame back at me about their right to use this "feature"). If a compiler allows long variable names, but only cares about the first N characters, it is possible to type the same variable name in different ways, e.g "variable_name" and "variable_nm" on compilers where the first ten characters are significant are considered the same variable. If a program refers to the variable by both names and there is an attempt to port it to a system with a twelve-significant-character compiler then the one variable will become two variables. I can think of no good reason for using two different names for the same variable, but I have read about cases like this. I suspect that they were mostly accidental, i.e. the programmer forgot which variable name form he was using. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
ignatz@aicchi.UUCP (Ihnat) (05/25/85)
Thanks to all who mailed to me--positive, negative, and a**holes--for at best, constructive agreement or criticism, and at worst, caring enough to spend the time to even carp at me. I'm going to answer all personal mail on this, and that's where I think it belongs after this; but I would like to rebut and comment on some items brought up. First, yes, I know what net.sources is for. (I've been a participant on the net since about '81...) OK, perhaps posting there was questionable; I *was* annoyed at the time, and wanted to at least guarantee that I caught the attention of those who may, in the future, be writing code; net.sources definitely caught some peoples' attention... Secondly, one person snarled something to the effect of "...what drivel to post...". Excuse me--I make my living in this field. I think, after something like 9 years, that I know how to evaluate problems and solutions. (Either that, or a lot of corporations are fools, and I'm the benefactor...yes, I'm leaving myself wide open, but I'm in sincerity mode right now) Portability is *not* drivel; it's the crux of the issue. If you're dealing with a client who's run an all-assembler shop until now, and try to tell him/her that a move to 'C' is a reasonable investment, what do you answer to their "why?" ? Usually, that they're then portable; no longer tied to machine XYZ, and development system FernDork. But if people start cranking out code for this guy that only works on one or two variants of the compiler, he's been sold a bill of goods; the first time they try to go to, say, an Altos environment running Xenix, they're going to realize that it just isn't reasonably feasible. And it's all so pointless; you can use your very long flexnames to give you meaningful names in your code; yet it's quite easy to use a naming convention that is *still* unique in the first, say, 7 characters. It's a rare case of having your cake and eating it, too--your code will now work on ALL systems, so why restrict it's portability and maintainability when it doesn't cost you anything? Yes, maintainability. Some suggested the use of 'clash'. Yes, I'm aware of the program--and I still maintain that it's not a reasonable alternative. The fellow who recounted his problem with GNU Emacs hit the issue dead center: updates, bug fixes, and maintenance become administrative nightmares. Not to mention that you now have to keep twice the source code, or more than double program generation time; not bad on small, occasional programs, but totally unacceptable if you're a business considering moving to a different environment. It would be all right if there were a large, determined swing in the industry to move to flex names--but there isn't, not yet. You won't see this filter down to the community at large for at least 2 years, and I think I'm being *very* conservative; commercial houses like Manx and Whitesmiths' are slow to make radical changes in their products until they're tested and proven. Till then, they can't even shop for a compiler to *buy*. Several suggested rewriting the compiler, assembler, linker, pcc, etc. Others, to buy new ones. Still others, to patch the extant ones. In all cases, I have to respond that we're not talking about a school or home environment. The client will *not* accept a solution that leaves them with what they see as a bastardized system that nobody else has ever seen, and that requires a guru when all they wanted was a development tool that was touted as allowing them to target a wide range of systems. They often don't control the pursestrings, or can't get the compiler on a type of system that has a market they'd like to break into. Finally, to end this too-long response, someone made the suggestion that they hadn't properly controlled their consultants. True--detailed review of design proposals is a critical concern when dealing with outside houses. But this is the place that--I hope--those who will become the programmers and designers of tomorrow will see and think on these issues, so that they will bring them up to, all too often, naieve clients who don't realize that this is even a concern. YOU are the professional, selling your expertise to your employer or client; YOU should attempt to make the product as flexible and usable as possible. And, to those who simply responded with vitriol, the same. Any further discussion is welcome, but unless the net at large wants to stir this up, I suggest a mail forum. And please, think about it; this is the type of thing that can make or break 'C' and, by common inference, Unix in the business world. Thanks for your indulgence, -- Dave Ihnat Analysts International Corporation (312) 882-4673 ihnp4!aicchi!ignatz
bc@cyb-eng.UUCP (Bill Crews) (05/31/85)
>It's simply an issue of compatibility. Unless you want to make your users >suffer unnecessarily, you should introduce new changes gradually, and wait >for the old ones to die out gracefully, rather than forcing new features >on the user. This feud has no possibility of being won, so long as the feuders continue to ignore the fact that contexts exist within which software development is performed. In some cases, programs are written intentionally to be quick and dirty (and, hopefully, throw-away). Local idioms would be called for if the development process is accelerated or made more reliable. Others publish software with which source code is distributed. Understandability would seem to be the key here. Still others develop source code which will likely be hacked into various forms and run on many different systems during its life. Perhaps in this case some understandability should be sacrificed for greater portability. By defining the realm of his concern to be COMPATIBILITY, the author has set his context, and the conclusions are obvious. But surely he doesn't believe that portability is the only consideration in the development of programs! I fall in the category of "long namers" because the bulk of the work I do involves large systems in which parts are written by various programmers who would have a difficult time repeatedly having to figure out what is meant by such variable names as bufav or even pktwait, when buffer_available and packet_waiting tell one just what is the meaning of the variable. On such projects, I must often reread and remember what *I* wrote several months earlier. But if I were writing code that only I read or maintained, which took only a few days to write, and which did not relate to external modules much, I would probably adopt a different style. Please try not to judge everyone else by your own circumstances and even prejudices. -- / \ Bill Crews ( bc ) Cyb Systems, Inc \__/ Austin, Texas [ gatech | ihnp4 | nbires | seismo | ucb-vax ] ! ut-sally ! cyb-eng ! bc
howard@cyb-eng.UUCP (Howard Johnson) (06/01/85)
>> you should introduce new changes gradually, and wait >>for the old ones to die out gracefully, rather than forcing new features >>on the user. > I agree with this statement, but I don't know how long I have to wait >for the old compilers to go away. Does somebody want to make a guide- >line for this? Depends on how much the customers are willing to pay for the new changes. And, of course, whether or not they are informed enough to know the differences.