From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,c9f2b97a84c48976 X-Google-Attributes: gidfdb77,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-ArrivalTime: 2001-07-05 19:48:03 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!cyclone2.usenetserver.com!newscon06.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr17.news.prodigy.com.POSTED!not-for-mail From: "Ken Garlington" Newsgroups: comp.lang.ada,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml,comp.lang.java.advocacy References: <9gsvr7$7ho$1@nh.pace.co.uk> <9folnd$1t8$1@nh.pace.co.uk> <3B1FE1FE.B49AE27F@noaa.gov> <9fotpi$4k6$1@nh.pace.co.uk> <3b24dc21$1@news.tce.com> <3B25D5FB.15C9B240@dresdner-bank.com> <9g5as6$hbq$1@magnum.mmm.com> <9g5ipg$roq$1@nh.pace.co.uk> <9g614i$at4$1@magnum.mmm.com> <9g7r02$mni$1@nh.pace.co.uk> <3b366a2b$6$fuzhry$mr2ice@va.news.verio.net> <9h7guv$pt1$1@nh.pace.co.uk> <3B3879CE.AC550F8E@acm.org> <3B3E73E8.F9C36524@ix.netcom.com> <3B405DDF.5C3F9207@acm.org> <3B416975.D7F0691D@ix.netcom.com> <3B432AD8.3828FB9@acm.org> <9i1q0r$324$1@nh.pace.co.uk> Subject: Re: Market pressures for more reliable software Organization: ex-FlashNet, now Prodigy X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <7F917.2087$jf.539468852@newssvr17.news.prodigy.com> NNTP-Posting-Host: 65.65.209.217 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr17.news.prodigy.com 994387651 6207069 65.65.209.217 (Thu, 05 Jul 2001 22:47:31 EDT) NNTP-Posting-Date: Thu, 05 Jul 2001 22:47:31 EDT Date: Fri, 06 Jul 2001 02:47:31 GMT Xref: archiver1.google.com comp.lang.ada:9530 comp.lang.java.programmer:80815 comp.lang.pl1:1204 comp.lang.vrml:3988 comp.lang.java.advocacy:22739 Date: 2001-07-06T02:47:31+00:00 List-Id: "Marin David Condic" wrote in message news:9i1q0r$324$1@nh.pace.co.uk... : You're wasting your breath. Sometimes people have such a strong need to be : right that they'll ignore all the reasoning and evidence to the contrary - : convoluting logic, redefining terminology, etc.. Often the original point is : totally forgotten in defending a position that isn't even related to it. : : Move on to more productive concerns. : : MDC If I understand the argument right, the proposed definition of "decentralized programming" is "the programmer did not physically stand at the CPU while working." By that definition, there *was* very little centralized programming. Even when I had to submit batch cards to an operator, who ran them through a reader standing next to the machine, I may have punched the cards myself on a remote keypunch. Even when I had to have someone sitting in the same room as the CPU punch the cards, I usually wrote the contents down at my desk via card layout sheets. Even when I had to physically key in programs at the console, I at least wrote flowcharts at my desk. So, for the given definition, I suppose the argument is technically true. However, if you consider the environment described by Brooks as "centralized programming," there was huge bunches of that when I got into the business, both in academia and commercial worlds. Anyone who would claim that the existence of HASP/JES (yay Houston!) significantly affected that model didn't work in the places where I worked (which had both, but still followed the Brooks model). The technology may have existed for large-scale "distributed" (in the sense of time-sharing, significant distance from the host, etc.), but a lot of organizations in the 70s and even 80s used a tightly controlled batch job scheduling approach to manage assets. To this day, if anyone says "OPTCD=Q" to me, I vow to hunt them down and kill them.