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
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!guyignatz@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