sean@ms.uky.edu (Sean Casey) (07/28/87)
A compiler isn't going to solve all the problems anyway. Most programs use
system specific features. A compiler can't resolve all of them. Try porting
an Amiga program that uses windows and bitblt graphics and 4 channel sound
to an IBM pc. So what is the solution? Never use system specific features?
Put #ifdefs to support every machine that the compiler runs on? No way!
What about people that happen to like their $400 (or $4000) dollar compilers?
Are they going to discard their investment for something that probably won't
nearly work as well?
Frankly, I'd rather see only source posted. Unfortunately, not everyone has
a compiler. Not everyone uses C either. Not everyone has the source to the
programs they post. What about PKARC or PROCOMM for the IBM pc? No
one is going to get source for them, but the community benefits by their
presence. The same goes for any shareware program or software that the
author does not wish to relase with source, as is his right.
Sean
--
-- Sean Casey sean@ms.uky.edu, {uunet,cbosgd}!ukma!sean
-- sean@ms.uky.csnet, sean@UKMA.BITNET
-- We want... a shrubbery!allbery@ncoast.UUCP (Brandon Allbery) (08/02/87)
As quoted from <6960@g.ms.uky.edu> by sean@ms.uky.edu (Sean Casey): +--------------- | Frankly, I'd rather see only source posted. Unfortunately, not everyone has | a compiler. Not everyone uses C either. Not everyone has the source to the | programs they post. What about PKARC or PROCOMM for the IBM pc? No +--------------- And then there's the problem I recently had: A VMS binary for a program written in Ada. So who's going to write the fully-validated PD Ada compiler? Agreed -- it *might* be nice if everyone could post sources. But, as the flip side of this, it'd be nice if I had C and Pascal and Modula 2 and Ada and Smalltalk and Prolog and APL and ... for both my PC and for ncoast. (Keep in mind, also, that APL _really_ requires the APL character set to get the most use out of it. I happen to have an APL terminal, but does everyone else?) [Yes, I know that Smalltalk is interpretive, but you get my point.] -- Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>
tes@whuts.UUCP (STERKEL) (08/03/87)
In article <3725@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes: > As quoted from <6960@g.ms.uky.edu> by sean@ms.uky.edu (Sean Casey): > +--------------- > | Frankly, I'd rather see only source posted. Unfortunately, not everyone has > | a compiler. Not everyone uses C either. Not everyone has the source to the > | programs they post. What about PKARC or PROCOMM for the IBM pc? No > +--------------- I do not know about the rest of the world, but lil-ol-me the run-of-the-mill user (non-hacker), has difficulty with about 70% of the C source put up on the Network. At least 90% *does not compile and/or link* leaving me to my poor wits to "fix". Ultimately, about 70% remains worthless. Most of this seems to be site/machine dependency of some sort, either by the poster or by my "home" machine. I frankly do not see where a PD C would help at all. -- Terry Sterkel {clyde|harvard|cbosgd|allegra|ulysses|ihnp4}!whuts!tes [opinions are obviously only my own]
webber@brandx.rutgers.edu (Webber) (08/05/87)
In article <2527@whuts.UUCP>, tes@whuts.UUCP (STERKEL) writes: > I do not know about the rest of the world, but lil-ol-me the > run-of-the-mill user (non-hacker), has difficulty with about 70% of > the C source put up on the Network. At least 90% *does not compile No need to act all bashful and such. The question you are raising is one that people who claim enough experience to moderate a sources group have failed to appreciate. > and/or link* leaving me to my poor wits to "fix". Ultimately, about > 70% remains worthless. Most of this seems to be site/machine > dependency of some sort, either by the poster or by my "home" > machine. I frankly do not see where a PD C would help at all. The reason that you are having problems with all of these programs is that they are usually sources that were only written under one version of one C compiler on one version of Unix running on one particular machine. You would have no problem reconstructing the executable that corresponds to the source if you had access to the C compiler, operating system, and computer used by the person who created the source. What PD C does is make one C compiler accessible to all, hence eliminating that weakness in the chain. Because the language is C, it is possible to write an entire operating system in the language, thus eliminating a second weakness in the chain. Unfortunately, there isn't much that can be done about making sure that everyone one uses the same computer. However, the portability of C has been greatly helped by the influence of the PDP-11/45 design on subsequent machine architectures. A completely different approach is to design a language that specifies computations in a manner completely independant of the computer and operating system on which it lies. While some languages do this better than other languages, no language does it well enough to tempt me away from C (although I do use Lisp sometimes to prototype things). ---- BOB (webber@aramis.rutgers.edu ; rutgers!aramis.rutgers.edu!webber)
gnu@hoptoad.uucp (John Gilmore) (08/06/87)
tes@whuts.UUCP (STERKEL) wrote: > I do not know about the rest of the world, but lil-ol-me the > run-of-the-mill user (non-hacker), has difficulty with about 70% of > the C source put up on the Network. At least 90% *does not compile > and/or link* leaving me to my poor wits to "fix". Ultimately, about > 70% remains worthless. Lil-ol-me has difficulty with 100% of the binary software put up on the network, even though I'm a Hacker and a Wizard. At least 90% *does not run* leaving me to my poor wits to "fix". But patching it with adb just doesn't seem to help. Ultimately, about 100% remains worthless. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@postgres.berkeley.edu Alt.all: the alternative radio of the Usenet.
guardian@laidbak.UUCP (Harry Skelton) (08/10/87)
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. 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). Some of the things I would outline is: Simple use of structures or multi-array useage. No externs or unions (if at all possible). straight use of variables - no pointer playing. NO TYPEDEFS - some machines will croak on this. (Hi SCO Xenix) Small moduals - better a few little programs doing something than one big one. LOTS OF COMMENTS - nuff said. Smart makefiles or config programs - to find out what the user does not know (see rn) No BSD or Sys V dependent stuff - must be able to compile 'clean' on any system. vars must have legable names - no pt.dk.i2.dv - put.disk.in2.drive <--- better no memory playing - no mallocs, allocs, callocs or whatever - if it cant be handled by the compiler then don't post it. use standard includes - stdio.h curses.h termcap.h ctype.h ect.... include complete documents.... 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. oh...main must be on bottom - plexus, IBM xenix (orig versions) and others have problems with main at top. (TRUE!) Harry Skelton guardian@laidbak.UUCP My opinions are not those of my company!
jte@psuvax1.psu.edu (Jon Eckhardt) (08/13/87)
I find it strange that people seam to be going after the binary groups because of traffic. The talk.bizarre and rec.humor groups have a high rate of useless traffic. I think that the creation of rec.humor.funny was a fantastic idea and I hope that that group will continue in existance. I do think that talk.bizarre and rec.humor are the types of thing that is usually on a private BBS, not a world wide network. I think that this sort of group does not really belong in such a large community with limited bugets as USENET. --Jon jte@psuvax1.BITNET UUCP = <allegra,ihnp4,atcgva,burdvax,purdue>!psuvax1!jte jte@psuvax1.psu.edu = ARPA --------------------------------------------------------------------------- PSU #1 Phone: 814-237-1901 Work: (leave message) 814-865-9505 PSU #1
allbery@ncoast.UUCP (08/15/87)
As quoted from <1101@laidbak.UUCP> by guardian@laidbak.UUCP (Harry Skelton): +--------------- | 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). Some of the things I would | outline is: +--------------- (long list deleted) You just invalidated 99% of the software that exists. Also, you cause major portability problems: (1) curses doesn't exist in most MS-DOS C compilers, ditto CP/M, probably also Mac and Amiga (2) Unix-developed conventions don't look too useful on a Mac. How do you make a fancy-screen program work in a Mac environment? (3) Typedefs enhance portability. If SCO blew it, we shouldn't pander to them: we should force them to fix their compiler. Maybe you should mail them any programs that won't compile... +--------------- | oh...main must be on bottom - plexus, IBM xenix (orig versions) and others have | problems with main at top. (TRUE!) +--------------- Of all the problems I've had with Plexus systems, that's not one of them. Which Plexus? (works fine on P/35, P/60, P/75, under Sys3 and Sys5.2) If it's the Z8000 versions, maybe the problem is Z8000 brain damage? (Since the Z8000 is another of those wonderful save-the-world segmented architec- tures...)
mouse@mcgill-vision.UUCP (der Mouse) (08/25/87)
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.... <termcap.h> 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)