Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!necntc!ames!aurora!labrea!decwrl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: news.admin Subject: Re: PD C as solution to binary groups Message-ID: <870@mcgill-vision.UUCP> Date: Mon, 24-Aug-87 21:34:09 EDT Article-I.D.: mcgill-v.870 Posted: Mon Aug 24 21:34:09 1987 Date-Received: Sat, 5-Sep-87 10:17:05 EDT References: <6960@g.ms.uky.edu> <3725@ncoast.UUCP> <2527@whuts.UUCP> <1101@laidbak.UUCP> Organization: McGill University, Montreal Lines: 112 In article <1101@laidbak.UUCP>, guardian@laidbak.UUCP (Harry Skelton) writes: > If a few changes were made to the Small-C compiler or a document for > standard idiot 'C' programming was made available, then I think this > could cure 85% of the problems. I don't think it's anything as simple to cure as that. The main problem, as I see it, is that the people writing the code are not good programmers. And no matter how many pages of guidelines you give to a bad programmer, you will still get incomprehensible or just plain wrong code. It may be very pretty wrong code, but still wrong. This is much like trying to say that "removing gotos makes code more readable", when in fact an incompetent programmer can (and will) write incomprehensible code with or without gotos, while a competent programmer can (and usually will) write clear code, regardless of whether it has or doesn't have gotos. > Some of the net has little or no brains when dealing with programming > or 'C' porting. (This is not to offend anyone but is true). I would amend that by striking out "when dealing...'C' porting". Sad but true. (I don't aim this jab at anyone in particular, since I don't remember the names of the people who most impress me as bozos, except for a few of the most stunningly bozoid.) > Some of the things I would outline is[sic]: > straight use of variables - no pointer playing. What is "pointer playing"? You mean, no usage of pointer variables? Sorry, that suddenly makes the language (almost) useless. > NO TYPEDEFS - some machines will croak on this. (Hi SCO Xenix) I refuse to write down to broken implementations. If it doesn't do typedefs, then in Guy's immortal phrase (did he ever actually use it?), it ain't C. EVERY definition of the language, from K&R through X3J11, has included typedefs. As someone (Chris Torek's name comes to mind) said, "shall we avoid using the * operator because some implementation might generate code to add 43 and if the result is negative, rewind the printer?". > no memory playing - no mallocs, allocs, callocs or whatever - if it > cant[sic] be handled by the compiler then don't post it. I also refuse to write down to deficient implementations, even if they aren't strictly broken. Is there anything out there that seriously pretends to be a C environment that doesn't supply malloc()? > Smart makefiles or config programs - to find out what the user does > not know (see rn) Unfortunately only a very few people, like Larry Wall (source of rn and patch and many other good things), are good enough to write a config smart enough to do what you want. Shall we ask Larry for a meta-config program? > No BSD or Sys V dependent stuff - must be able to compile 'clean' on > any system. Oh. I guess we mustn't try to do character-at-a-time terminal I/O. We can't try to read directories. Mustn't use any of the string functions (strtok, index, rindex, memcpy, etc). What a *useful* language this will be. Riiiight. > vars must have legable names - no pt.dk.i2.dv - put.disk.in2.drive How about corectlly speled documentatiun? (What do you have against "into", anyway?) > use standard includes - stdio.h curses.h termcap.h ctype.h ect.... doesn't exist on our system (BSD4.3); and because SV is trying to use terminfo instead of termcap, I would doubt it exists there either....what was that about no system-dependent stuff? > include complete documents.... I'd rather have two useful programs with only manpages for documentation than one useful program with handholding manuals. Or does a manpage qualify as "complete" documentation? I would also prefer to have the (all too few) good programmers do what they do best - programming - and leave the documentation up to the people who do *that* well. (The problems lie in finding (and identifying, and coordinating the efforts of) both sorts of person.) > The list goes on and on. If anyone would like to see such a document > of what is good and what is bad, post your vote and I'll comprise a > complete listing and let you post what works and what does not. This > way we can find what is compatable between machines. Unfortunately, what I want in a posted program cannot be produced by simply giving people a checklist of guidelines. As I mentioned above, a good programmer can (and usually will) produce good code without needing the checklist; and a bad programmer will still produce bad code, even if it conforms to the letter of any such checklist. So I guess what I want is to see just the programs from the good programmers. Now all we need to do is tell the difference.... > oh...main must be on bottom - plexus, IBM xenix (orig versions) and > others have problems with main at top. (TRUE!) Again, I refuse to write down to broken implementations. I thought you wanted things modularized? Then shouldn't main be in a file of its own anyway? der Mouse (mouse@mcgill-vision.uucp)