sl195@cc.usu.edu (A banana is not a toy) (12/06/90)
In article <9012040257.AA10743@ucbvax.Berkeley.EDU>, 91_bickingd@GAR.UNION.EDU ("Bicking, David") writes: > Date sent: 3-DEC-1990 20:56:41 >> >> [ deleted stuff about a Byte article comparing the A3000 to the n*xt] > > On a similar idea, I believe the ultimate test of how well a program is > written is to run it on a 7Mhz 68000 amiga :) I would think it would be ^^^^^^^^^^ Amen. Along with the faster CPUs, cheaper RAM, bigger HDs, I've seen a trend to NOT optimize software. "Let the compiler do it." That's nice, but the best optimizing compiler can't make up for human laziness. Sloppy software on a fast machine is as good as well-written software on a slow one. I'm not impressed with n*xt's multi-megabyte OS. That's worse than i*m's OS/2!!! Come on, guys. I know that the market is tough, and you have to get stuff out before the "other guy" in order to stay afloat, but how about some _quality_? I realize that there is a minimum size for any software, but I find it hard to believe that the n*xt OS has come close to that. Having a multi-megabyte OS is one of the fastest ways to get me to not buy a computer. I hope that C= hasn't taken short cuts with the 3000UX like it appears that n*xt has. ************ My best software on my *** A500 *** screams, and is compact. No FPU, no MIPS. Just efficent ************ code. (If it screams on a A500 I'd love to try it on a 3000 :-) P.S. eunics (un*x :-) is not a plus in my book. I have to work with it, and don't enjoy it. > standard practice to optimize a program on such a platform, as the speed > difference is most noticable at that level! > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=- > Dave Bicking Single Tasking????? Just say NO!!!! > Union College Box 152 91_bickingd@union.bitnet // > Schenectady, NY 12308 91_bickingd@gar.union.edu \X/ Amiga > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- All comments are my own, and many must be taken with a :-) =============================++++++++++++++++++++============================= | Demetrios Triandafilakos | James Knowles | "Remember, always remember,| | Shire of Cote du Ciel | BITNET: SL195@USU | my son -- a banana is not | | Principality of Artemesia | INTERNET: | a toy." | | Kingdom of Atenvelt | sl195@cc.usu.edu | - The Wise Guru | =============================++++++++++++++++++++============================= Be all that you can be - see your local SCA Knight Marshal now.
gilgalad@caen.engin.umich.edu (Ralph Seguin) (12/11/90)
In article <1990Dec5.233501.43949@cc.usu.edu> sl195@cc.usu.edu (A banana is not a toy) writes: >Amen. Along with the faster CPUs, cheaper RAM, bigger HDs, I've seen a >trend to NOT optimize software. "Let the compiler do it." That's nice, but Certainly true. There is no excuse for not trying to write the best code possible. >the best optimizing compiler can't make up for human laziness. Well, this is debatable :) Compilers can do some amazing optimizations. I think that quite a few things should be left to the compiler, but writing good code isn't one of them :) >Sloppy software on a fast machine is as good as well-written software on a >slow one. Most certainly true. Who says that UNIX code is all that sloppy? >I'm not impressed with n*xt's multi-megabyte OS. That's worse than i*m's >OS/2!!! Come on, guys. I know that the market is tough, and you have to I have to disagree with this. We all know that OS/2 is a piece of junk. Have you EVER used BSD UNIX with NeXTStep tacked on top? >get stuff out before the "other guy" in order to stay afloat, but how about >some _quality_? I realize that there is a minimum size for any software, >but I find it hard to believe that the n*xt OS has come close to that. What? I don't understand. Are you trying to say that it takes up too much disk space for the NeXT OS? It's UNIX. UNIX almost by definition is a disk hog. >Having a multi-megabyte OS is one of the fastest ways to get me to not buy >a computer. I hope that C= hasn't taken short cuts with the 3000UX like it >appears that n*xt has. What shortcuts are these? If I were going to be getting a 3000UX or 4000UX, I would in no way want anything less than a 600 meg disk. Same goes for any UNIX box for me. >My best software on my *** A500 *** screams, and is compact. No FPU, no >MIPS. Just efficent ************ code. (If it screams on a A500 I'd >love to try it on a 3000 :-) Must agree, efficient code is the only way to fly. Efficient code is not just limited to the Amiga you know. >P.S. eunics (un*x :-) is not a plus in my book. I have to work with it, and >don't enjoy it. This is a religions matter :) Personally, I love UNIX. Amiga OS is VERY UNIX-like, minus multi-user stuff and vm. >> standard practice to optimize a program on such a platform, as the speed >> difference is most noticable at that level! Standard practice is to produce the best general algorithm with lowest complexity level. >-- > >All comments are my own, and many must be taken with a :-) >=============================++++++++++++++++++++============================= >| Demetrios Triandafilakos | James Knowles | "Remember, always remember,| >| Shire of Cote du Ciel | BITNET: SL195@USU | my son -- a banana is not | >| Principality of Artemesia | INTERNET: | a toy." | >| Kingdom of Atenvelt | sl195@cc.usu.edu | - The Wise Guru | >=============================++++++++++++++++++++============================= > Be all that you can be - see your local SCA Knight Marshal now. See ya, Ralph Ralph Seguin gilgalad@dip.eecs.umich.edu 536 South Forest Apt. #915 gilgalad@caen.engin.umich.edu Ann Arbor, MI 48104 (313) 662-4805
farren@well.sf.ca.us (Mike Farren) (12/11/90)
gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >Most certainly true. Who says that UNIX code is all that sloppy? I do, for one. Ever seen the Bourne shell source? -- Mike Farren farren@well.sf.ca.us
fnf@riscokid.UUCP (Fred Fish) (12/12/90)
In article <22109@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: > >>Most certainly true. Who says that UNIX code is all that sloppy? > >I do, for one. Ever seen the Bourne shell source? Not exactly an appropriate topic for comp.sys.amiga, but since when has that stopped anyone... :-) Most of the absolutely worst C code I've ever seen has been in the course of maintaining Unix utilities over the last eight years or so. Try peeking at the source to sdb or the COFF linker for example. Before I actually had a chance to see AT&T's source, I had envisioned that such an elegantly designed system (compared to what I'd been working on) surely had jewels of programming expertise that a newbie C program such as myself could admire and learn from. Imagine my shock and horror at finding routines that ran on for hundreds of lines with all kinds of early terminations, nesting of conditionials and switches a dozen levels deep, sloppy typing of variables, etc. Gack! -Fred
daveh@cbmvax.commodore.com (Dave Haynie) (12/18/90)
In article <14240@mcdphx.phx.mcd.mot.com> fnf@riscokid.UUCP (Fred Fish) writes: >In article <22109@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >>gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >> >>>Most certainly true. Who says that UNIX code is all that sloppy? >>I do, for one. Ever seen the Bourne shell source? >Most of the absolutely worst C code I've ever seen has been in the course >of maintaining Unix utilities over the last eight years or so. Probably true, though I have found that the popular UNIX systems of the past few years, especially VAXen, make it easy to write bad code. What, I'm blaming it on the machines?!? Yup. For example, a few years ago I wrote a real quick program in C on our VAX to read in our standard netlist interchange file format and spit out a corresponding, nicely formatted, bill of materials. It worked great, never had a problem with it. Then our VAX changed to a MIPS, and the thing didn't even begin to compile. Since I had better C tools by that time on the Amiga, I tried it there. I found the easy bugs, like where I said thing *x[256] but meant thing x[256] But that should have been found on the VAX, at least at runtime -- this was, after all, a protected memory UNIX machine, not a "silly pc". And of course, the Lattice compiler kicked up all kinds of type warnings and the like that UNIX compilers always ignore. Bugs like this are always the programmer's fault, of course, but systems and compilers that let you get away with blatent bugs and encourage bad programming don't help the generation of good code. By the way, the program still isn't working on any of the systems. One of these days I'll have the time to fix it.... >-Fred -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I can't drive 55" -Sammy Hagar
smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) (12/22/90)
In article <14240@mcdphx.phx.mcd.mot.com> fnf@riscokid.UUCP (Fred Fish) writes: <In article <22109@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: <>gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: <> <>>Most certainly true. Who says that UNIX code is all that sloppy? <> <>I do, for one. Ever seen the Bourne shell source? < <Not exactly an appropriate topic for comp.sys.amiga, but since when <has that stopped anyone... :-) < <Most of the absolutely worst C code I've ever seen has been in the course <of maintaining Unix utilities over the last eight years or so. Try peeking <at the source to sdb or the COFF linker for example. Before I actually <had a chance to see AT&T's source, I had envisioned that such an <elegantly designed system (compared to what I'd been working on) surely <had jewels of programming expertise that a newbie C program such as myself <could admire and learn from. Imagine my shock and horror at finding <routines that ran on for hundreds of lines with all kinds of early <terminations, nesting of conditionials and switches a dozen levels deep, <sloppy typing of variables, etc. Gack! < <-Fred Some time ago we got hold of the source to the infamous Silicon Graphics Flight Simulator. That one program alone probably helped sell half of their machines. I was prepared to be humbled by near god-like coding so elegant and clear that a 4rth grader could understand. I was going to be ushered into the inner secrets of the great programmers, blah, blah, blah... Boy was I in for a letdown. main() was 1364 lines long! It contained nearly all of the programs logic, making only occaisional calls to do some rendering. It looked like a first year college student project on steroids. It sure gave me much more confidence in my own abilities, and much less in Silicon Graphics. Then I got a look at VAX Unix kernal source. YUCK! Certainly a fine example of how not to code. >> mike smithwick << Any opinions are my own since nobody else would ever want them. "Colonize Cyberspace!"