Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!amd!intelca!oliveb!felix!chuck
From: chuck@felix.UUCP
Newsgroups: comp.edu
Subject: Microcomputers and Productivity
Message-ID: <5715@felix.UUCP>
Date: Mon, 17-Aug-87 13:34:22 EDT
Article-I.D.: felix.5715
Posted: Mon Aug 17 13:34:22 1987
Date-Received: Thu, 20-Aug-87 01:32:33 EDT
References: <398@ndsuvax.UUCP> <18100001@infbs.UUCP>
Sender: daemon@felix.UUCP
Reply-To: chuck@felix.UUCP (Chuck Vertrees)
Organization: FileNet Corp., Costa Mesa, CA
Lines: 38
Summary: They may be fast, but can slow you down.

In article <18100001@infbs.UUCP> neitzel@infbs.UUCP writes:
>  [summary and previous discussion about using microcomputers and the
>   kind of turnaround involved.]
>But there is nothing bad about waiting for something!
>In fact it gives you a good opportunity for talks with all other
>students waiting for printouts, too.  Students that work on the same
>problem.
>  [More detailed discussion about this topic]

In addition to the loss of communication between people that accompanies the
individual use of microcomputers, I believe the more damaging loss is in
programmer discipline.  By this, I refer to the ease with which one can
reprocess a program, and the resulting trap one can fall into.  Because of this
speed, many programmers tend to let the compiler or interpreter do their
debugging for them.  Less effort is put into understanding the problems which
are occurring.  Superficial changes are made to programs which are then
reprocessed to check out the modifications.  The net effect can easily become
counterproductive.

Yes, machines are fast and getting faster.  Yes, compilers are good and getting
better.  But this does not substitute for understanding the problems you are
dealing with.  You may be able to change your program 15 (or more) times,
recompile and run it during a day.  If you are just using a shotgun approach,
you really are not any further ahead than you would have been if you just sat
at your desk and read the code.

Lets go back 15 years.  Before you submitted your 100 line FORTRAN program to
your university batch processor, you spent a great deal of time ensuring that
it was correct.  After all, it could normally take you three hours to get the
results.  You didn't want to waste that time with a syntax error, or a
transposition of a logic test.  You spent part of that time desk checking your
code for correctness.

Modern language processors may remove the drudgery involved in ensuring correct
syntax, but they won't ensure your logic is correct.  If you just continually
make changes you don't understand to a program, you may indeed finally get it
right.  The temptation to do this is very high since it is so easy to
re-process the program.  But that may not be the best way to solve the problem.