phipps@fortune.UUCP (Clay Phipps) (06/11/84)
I learned programming in an interactive environment:
Wang 300 series calculators (in high school) and GE Timesharing BASIC.
Most of my subsequent undergraduate programming was done via batch on an
IBM S/360 model 65 (back when a megabyte was *lots* of memory) and OS/360.
I agree with many of the points made in the original posting,
but have found that they do not hold up in the "real world"
of computing education, where students do not exhibit the desired behavior
under the pressures of assignments, exams, and term projects.
There is an important aspect of off-line development that was not mentioned:
many off-line environments are notoriously overloaded.
The students using them are intensely aware of delays (measured in hours
or worse) caused by slow turnaround. One consequence is that many students,
especially those under some form of schedule pressure (assignment deadlines),
will rush their work to get their programs back into the off-line job
submittal queue. This might be most accurately considered a form of panic.
The net effect is that many students will exercise *less*, rather than more,
care in off-line work.
-- Clay Phipps
--
{cbosgd decvax!decwrl!amd70 harpo hplabs!hpda ihnp4 sri-unix ucbvax!amd70}
!fortune!phippsmp@whuxle.UUCP (Mark Plotnick) (06/13/84)
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.gurr@west44.UUCP (Dave Gurr) (06/20/84)
< force of habit .. > > 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. This philosophy is *dangerous*. Anyone out there remember the concept of ego-less programming? If you get so tied up with a program that you are embarrassed and upset about finding bugs, you may also convince yourself that other shortcomings in the program don't exist. I'm sorry if this sounds like a flame - it isn't supposed to. If anyone wants a reference to the ego-less programming concept, mail me and I'll dig it out. (On the other hand, maybe some kind soul out there in netland could provide a really good list of refs. on this?) <That's not a bug, it's a feature ....!> mcvax \ ukc!west44!gurr / vax135 Dave Gurr, Westfield College, Univ. of London, England.