Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site whuxle.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!whuxle!mp From: mp@whuxle.UUCP (Mark Plotnick) Newsgroups: net.lang Subject: Re: Batch Programming / Re: ..., Going Off-line Message-ID: <443@whuxle.UUCP> Date: Tue, 12-Jun-84 23:36:33 EDT Article-I.D.: whuxle.443 Posted: Tue Jun 12 23:36:33 1984 Date-Received: Wed, 13-Jun-84 06:43:22 EDT References: <1044@vax2.fluke.UUCP> <3572@fortune.UUCP> Organization: Bell Labs, Whippany Lines: 44 Computer courses at MIT over the past few years have had facilities ranging from batch environments with 029 keypunches to single-user 68000 systems with bitmapped screens. To some extent, these differences were not based on deep-seated beliefs in methodology, but were instead due to economic considerations; some departments couldn't afford their own computers or terminals, or had a large investment in IBM software already developed for the course, so they used the comp center's IBM machine and punched cards. In other cases, the decision to go batch or interactive depended on the application; if the assignment involved writing a billing, inventory, and delivery scheduling program, it would be done on the batch machine. If the assignment consisted of writing an interactive query system or a spreadsheet calculator, then obviously an interactive system would be used. One definite advantage of the batch environment offered by the management dept's computer courses was that the students tended to pace themselves better. When you know that you're only going to get 1 run per day, you tend to start your assignment sometime prior to due date eve. I'm not going to discuss the differences in philosophy of the various faculty members, but here's a quote that's been causing some discussion on another (non-usenet) mailing list. Date: Sun 20 May 84 18:48:40-EDT From: SAZ%MIT-OZ@MIT-MC.ARPA The following paragraph appeared in the Course Notes for [an undergraduate computer course] under the section heading "Defensive Programming": The word "bug" is in many ways misleading. Bugs do not crawl unbidden into our programs. We put them there. DON'T THINK OF YOUR PROGRAM AS "HAVING BUGS;" THINK OF YOURSELF AS HAVING MADE A MISTAKE. Bugs do not breed in programs. If there are many bugs in a program, it is because the programmer has made many mistakes. You should never be proud when you track down a bug in your own program. It's like finding a cockroach in your kitchen. You should be embarrassed and upset that it was there in the first place.