Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!linus!philabs!cmcl2!seismo!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.works
Subject: Re: grisly grizzled programs
Message-ID: <372@terak.UUCP>
Date: Wed, 13-Feb-85 13:16:07 EST
Article-I.D.: terak.372
Posted: Wed Feb 13 13:16:07 1985
Date-Received: Sun, 17-Feb-85 05:38:23 EST
References: <596@topaz.ARPA>
Organization: Terak Corporation, Scottsdale, AZ, USA
Lines: 54

[ 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