@RUTGERS.ARPA:LINDSAY@TL-20A.ARPA (02/12/85)
From: LINDSAY@TL-20A.ARPA This post is rated "PG". Seventeen years ago, I was hacking in half-a- dozen or more languages, so I volunteer to be the adult that leads you through the following thicket: > This commentary is rated "R". It contains subject matter which is > considered heretical by anyone with less than 17 years experience, > and less experienced readers must be accompanied by a grizzled > old-timer. > > Programs were punched on cards, and listed off-line on > equipment such as the IBM 407 accounting machine. > > We produced more programs, bigger programs, and better programs, > under those conditions than programmers do under current conditions. Summary: No we didn't. 1) Coding was such a damn pain that programs were never cleaned up, and were left alone as much as possible. Now, programs have a lot more polish. 2) Allow me to point out that Unix's early popularity was due to "ed" and "nroff". Bell Labs embraced Unix as a way to ( get this ) document. In the Good Old Days we had secretaries type up our chicken scratchings. Maybe. Perhaps we would draw a flowchart. The comments were lousy (see point 1). 3) We didn't know beans about modularity. Dijkstra's ideas came later. Parnas' ideas about information hiding came later. Most programmers had learned by doing maintenance on the most ******** **** you ever saw. Mostly they'd never met anyone good to learn from. 4) I didn't learn discipline from waiting around. I learned it from others, and from projects that couldn't have their correctness tested in, and from working on things too big to keep entirely in my head (note point 3, above). I learned quite a lot, and I recommend the attitude that there's more to learn. Don Lindsay -------
doug@terak.UUCP (Doug Pardee) (02/13/85)
[ I couldn't *think* of letting this go unchallenged! ] > > We produced more programs, bigger programs, and better programs, > > under those conditions than programmers do under current conditions. > > Summary: No we didn't. > > 1) Coding was such a damn pain that programs were never cleaned up, and were > left alone as much as possible. Now, programs have a lot more polish. Polish???? You call $#!+ like Unix(tm) polished??? Sheesh! Now if *any* Unix program should be bug-free, it's "ls". After all, every one of us at every Unix site in the world uses it many times a day. Here is the bug list for "ls" on VAX/UNIX 4.2BSD. ::BUGS :: Newline and tab are considered printing characters in file :: names. :: :: The output device is assumed to be 80 columns wide. :: :: The option setting based on whether the output is a teletype :: is undesirable as ``ls -s'' is much different than :: ``ls -s | lpr''. On the other hand, not doing this setting :: would make old shell scripts which used _ls_ almost certain :: losers. :: ::Printed 2/13/85 28 July 1983 3 C'mon on now, try to tell me that "ls" is polished when it can't deal with terminals with screen widths other than 80 columns. And how much work would it take to recognize newline and tab characters and print (e.g.) "\n" and "\t" respectively? And this manual page is, by its own admission, a year and a half old! Can it really take a year and a half to fix these problems????? I don't know what *you* were up to back then, but when one of my programs turned up a bug I fixed the thing on the spot. And without wanting to seem immodest, my programs seldom turned up bugs (a situation that has deteriorated over the years as I've been forced into the current on-line setting). > 3) We didn't know beans about modularity. Dijkstra's ideas came later. Parnas' > ideas about information hiding came later. Most programmers had learned by > doing maintenance on the most ******** **** you ever saw. Mostly they'd never > met anyone good to learn from. This is totally beside the point of whether or not on-line systems promote poor programming practices. In fact, it argues that the bad effects of on-line programming are powerful enough to have overcome advances like modularity and information hiding. -- Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug
chris@umcp-cs.UUCP (Chris Torek) (02/16/85)
Ok, let's actually take this real example of "ls" bugs (4.2BSD manual):
Newline and tab are considered printing characters in file names.
Now seriously, how often do you find file names with newlines and tabs
in them? Has *anyone* ever *really wanted* ls to print \n or \t?
The output device is assumed to be 80 columns wide.
Fixed in ours. (Reads termcap.) (Or at least it did under 4.1; I don't
know if I ever reinstalled that change.)
The option setting based on whether the output is a teletype is
undesirable as ``ls -s'' is much different than ``ls -s | lpr''.
On the other hand, not doing this setting would make old shell
scripts which used ls almost certain losers.
This one even *explains* why this is done this way. The "shell scripts
which used ls" are *user* programs; there's not much Berkeley can do
about those. This "bug" entry really just explains (in a poor sort of
way) why you should use -C all the time....
The Unix manuals have their problems, but the "BUGS" entry is a feature. :-)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandguido@boring.UUCP (02/17/85)
In article <3284@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >Ok, let's actually take this real example of "ls" bugs (4.2BSD manual): > Newline and tab are considered printing characters in file names. >Now seriously, how often do you find file names with newlines and tabs >in them? Has *anyone* ever *really wanted* ls to print \n or \t? This is a clear specimen of the attitude which makes Unix still look so much like what it originally was: a programmers' toy. Programs that ignore lines longer than 256 characters, core-dump on illegal input, ignore invalid flag arguments, run exponentially slow for large input (due to a bad algorithm, not the problem's nature), leave the terminal in a strange state when interrupted, incredibly complex calling conventions, undocumented options that are used by everybody, mysterious incantations in one's .profile, und, und... These are abundant in most versions of Unix. This may be acceptable in a system that's mostly used by experts who wrote it themselves and "just want their job done", it's not in Unix as it is currently used: a user-friendly time-sharing system, or a powerful personal computer's OS. It is more than time that the programmers realize this and start writing programs that can stand whatever the users do with them -- the program should either perform well or produce an understandable diagnostic. Of course we can't write bug-free programs, but when a bug is discovered it should be fixed, and not replied to with phrases like the above. (BTW, ls should print '?' for \n and \t. I suppose it's a two-line change. Chris, this is your chance to be able to boast "fixed in our version..." -- which was completely beside the point the original author made. :-) Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido@mcvax.UUCP
doug@terak.UUCP (Doug Pardee) (02/18/85)
> Ok, let's actually take this real example of "ls" bugs (4.2BSD manual): > > Newline and tab are considered printing characters in file names. > > Now seriously, how often do you find file names with newlines and tabs > in them? Has *anyone* ever *really wanted* ls to print \n or \t? This misses the point. The point is not whether or not it is a major problem. 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. -- Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug
chris@umcp-cs.UUCP (Chris Torek) (02/19/85)
[First, side issue: I just checked, and lo and behold, our ``ls'' really
*does* print ``?'' for newlines and tabs embedded in file names.]
However, my point (which wasn't in my original followup, for shame!) is
that I believe it's better to actually *say*
BUGS
This program occasionally does the wrong thing
rather than covering it up, making people find it out for themselves.
I agree that it's better still if the program always does the ``right''
thing, but when it doesn't and there isn't enough incentive to fix it,
it should at least be documented. This is what the BUGS section is for.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandwaynez@houxh.UUCP (W.ZAKARAS) (02/19/85)
Come on now, please UNIX(tm) is the best sytem I've ever worked on and I bet 90 % of netter use it. How many operating systems have BUG reports? (I don't know the answer.) WHy not go back to stuff like RSM 11 or is it RSX 11. Have fun with it, I'll keep UNIX(tm) WayneZ...
karsh@geowhiz.UUCP (Bruce Karsh) (02/21/85)
> 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!
henry@utzoo.UUCP (Henry Spencer) (02/21/85)
> Sheesh! Now if *any* Unix program should be bug-free, it's "ls". After > all, every one of us at every Unix site in the world uses it many times > a day. Here is the bug list for "ls" on VAX/UNIX 4.2BSD. > > :: Newline and tab are considered printing characters in file > :: names. > :: The output device is assumed to be 80 columns wide. > :: The option setting based on whether the output is a teletype > :: is undesirable as ``ls -s'' is much different than > :: ``ls -s | lpr''... > > C'mon on now, try to tell me that "ls" is polished when it can't deal > with terminals with screen widths other than 80 columns. And how much > work would it take to recognize newline and tab characters and print > (e.g.) "\n" and "\t" respectively? And this manual page is, by its own > admission, a year and a half old! Can it really take a year and a half > to fix these problems????? Actually, it can be fixed in five minutes if you still have a V7 tape. The real bug behind all of the things mentioned is having ls know about terminals at all. This is Berklix brain-damage, not a flaw in Unix. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gjk@talcott.UUCP (Greg Kuperberg) (03/04/85)
> This is a clear specimen of the attitude which makes Unix still look so much > like what it originally was: a programmers' toy. ... > This may be acceptable in a system that's mostly used by experts who wrote > it themselves and "just want their job done", it's not in Unix as it is > currently used: a user-friendly time-sharing system, or a powerful personal > computer's OS. It is more than time that the programmers realize this and > start writing programs that can stand whatever the users do with them -- > the program should either perform well or produce an understandable > diagnostic. ... > Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam > guido@mcvax.UUCP It is still a programmers toy, because it is still written in C. Because of this, it also whatever you want it to be: user-friendly, user- unfriendly, personal, time-sharing, a network system, a games system, a research system, compatible, utterly incompatible, and so on. This is the power of Unix. Actually, in order to put it on the personal computers, you usually need to optimize to assembly language, at which point it loses all its magic. --- Greg Kuperberg harvard!talcott!gjk "2*x^5-10*x+5=0 is not solvable by radicals." -Evariste Galois.