Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site geowhiz.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!uwvax!geowhiz!karsh From: karsh@geowhiz.UUCP (Bruce Karsh) Newsgroups: net.works Subject: Re: grisly grizzled programs Message-ID: <162@geowhiz.UUCP> Date: Thu, 21-Feb-85 00:09:27 EST Article-I.D.: geowhiz.162 Posted: Thu Feb 21 00:09:27 1985 Date-Received: Tue, 26-Feb-85 08:23:07 EST References: <596@topaz.ARPA> <372@terak.UUCP> <3284@umcp-cs.UUCP> <379@terak.UUCP> Organization: UW Madison, Geology Dept. Lines: 74 > The point is that the problem has been known to exist for many years, > is absolutely trivial to fix, and yet *has never been fixed*. > > This is in direct contradiction to a claim that (in general) programs > which were produced on-line are "more polished" than the programs > that used to be produced using batch methods. Oh come on now. There weren't too many examples of polished batch programs back then. Remember how batch systems used to handle bad input? Let me remind you: IHE806I DATA INTERRUPT CORE DUMP FOLLOWS 0000000 4272 7563 6520 4b61 7273 6820 2020 2020 0000020 2020 2020 2020 2020 2020 2020 2020 2020 0000040 2020 2020 2020 7c20 4573 7065 7261 6e74 0000060 6f3a 2074 6865 2055 6e69 7665 7273 616c 0000100 2053 6563 6f6e 6420 4c61 6e67 7561 6765 0000120 0a55 2e20 5769 7363 2e20 4465 7074 2e20 0000140 4765 6f6c 6f67 7920 616e 6420 4765 6f70 0000160 6879 7369 6373 207c 2020 4561 7379 2074 0000200 6f20 6c65 6172 6e2e 2020 506f 6c69 7469 0000220 6361 6c6c 7920 6e65 7574 7261 6c2e 0a31 0000240 3231 3520 5720 4461 7974 6f6e 2c20 4d61 0000260 6469 736f 6e2c 2057 4920 3533 3730 3620 0000300 2020 2020 207c 2020 5370 6f6b 656e 2062 0000320 7920 6d69 6c6c 696f 6e73 2069 6e20 3130 0000340 3020 636f 756e 7472 6965 732e 0a28 3630 0000360 3829 2032 3632 2d31 3639 3720 2020 2020 0000400 2020 2020 2020 2020 2020 2020 2020 2020 0000420 2020 207c 2020 3130 3020 6d61 6761 7a69 0000440 6e65 732c 2074 686f 7573 616e 6473 206f 0000460 6620 626f 6f6b 732e 0a7b 6968 6e70 342c 0000500 7365 6973 6d6f 7d21 7577 7661 7821 6765 0000520 6f77 6869 7a21 6b61 7273 6820 2020 207c 0000540 2020 5365 6e64 2066 6f72 2074 6865 2046 0000560 7265 6520 506f 7374 616c 2043 6f75 7273 Hardly looks polished to me. You could probably count on the fingers on one hand the number of programs that actually did any input checking. Does anybody remember what the equivalent of the ls command was like under IBM's OSMVT? Does anybody prefer it to the ls command under U*NIX? What I remember from back then is that I was continually cutting back on the scope of problems that I tried to tackle. I didn't use the best algorithms and I didn't try to do things in new better ways because the machine got in the way. I also remember that the reason that there was 6 hour turnaround on jobs was because of people who would not fully debug their programs before resubmitting them. Probably fully 95 percent of the jobs batch jobs back then died with fatal errors. Normal completion was certainly not the norm. Of course it's nice to think that I was more careful and didn't throw in partially debuged jobs, but I'm probably just kidding myself. Yes, I remember the old days. And yes, I think that programmers should spend a lot more time planning, checking, and designing. But I don't remember that there was a whole lot more planning, checking, and designing back then. -- Bruce Karsh | Esperanto: the Universal Second Language U. Wisc. Dept. Geology and Geophysics | Easy to learn. Politically neutral. 1215 W Dayton, Madison, WI 53706 | Spoken by millions in 100 countries. (608) 262-1697 | 100 magazines, thousands of books. {ihnp4,seismo}!uwvax!geowhiz!karsh | Send for the Free Postal Course today!