Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!mit-amt!mit-caf!vlcek
From: vlcek@mit-caf.MIT.EDU (Jim Vlcek)
Newsgroups: comp.lang.c
Subject: Re: optimization (was Re: C vs. FORTRAN (efficiency))
Message-ID: <3019@mit-caf.MIT.EDU>
Date: 21 Aug 89 17:44:51 GMT
References: <3288@ohstpy.mps.ohio-state.edu> <225800204@uxe.cso.uiuc.edu> <14523@bfmny0.UUCP> <1613@mcgill-vision.UUCP> <14556@bfmny0.UUCP> <484@gistdev.UUCP> <1989Aug18.152547.10774@algor2.uu.net> <1989Aug20.024207.29079@utzoo.uucp>
Reply-To: vlcek@mit-caf.UUCP (Jim Vlcek)
Organization: Microsystems Technology Laboratories, MIT
Lines: 54

Henry Spencer takes issue, in <1989Aug20.024207.29079@utzoo.uucp>,
with another poster who theorizes that too-fast compiles make for
worse programmers:

``This same "making programming easier will make programmers sloppy"
  argument has been used against everything from timesharing to high
  baud rates on terminals.  It's been nonsense every time, and I think
  it's nonsense this time too.

``... have you ever used a punchcard-based batch environment with a
  turnaround measured in hours?  I have.  I'll take timesharing, thank
  you.  And I'll take the fastest compiles I can get.''

This recalls for me a comical episode nine years ago, when I left St.
Petersburg Jr. College in Clearwater, FL, to come to MIT.  Many of my
friends at the JC went on to University of Florida at Gainesville.
During my first term at MIT, I took a course called ``Structure and
Interpretation of Computer Programs'' which was quite good to its
word.  It involved a lot of Lisp programming (some Algol in the
middle), and was done on 9600 baud CRTs talking to a DEC-20.  It was
the first course I ever took which taught real _programming_, as
opposed to mere _coding_ (which is what a lot of ``programming''
courses actually teach), and it taught it exceedingly well.

At the same time, my friends from the JC were taking a course in
Fortran (required for all engineering majors) at UF which involved,
you guessed it, punching up card decks and then submitting them for
compilation and execution.  Usually, when you came back the next day,
you received a listing of syntax errors - most often words misspelled
by one letter, etc.

What amused me no end was that my friends did not envy me for having
had access to more powerful resources; no, they genuinely pitied me!
They honestly felt that I had been robbed, in that I had not been
forced to develop the ``careful programming practices'' that batch
environments demanded.  And, given their druthers, they would choose
to do things the way they had...  I wonder, even now, whether many of
these people _ever_ got the chance to see what programming is really
about.

My experience has been that the quality of my programming style is
relatively independent of the resources available to me.  What _is_ a
function of the resources available is the size and sophistication
of the applications which can be developed.  For this reason, I
disagree with those who hold the 11th commandment to be ``Always
develop your application on the machine upon which it will be run.''
(Notice I say develop; validation is yet another thing.)  I could
_never_ have gotten my PhD thesis work, a control system for an
automated crystal grower, done on the PC-XT upon which it runs.  And,
in developing it elsewhere, I probably learned a lot about portable
coding (which I think is an almost unqualified ``good thing'') which I
wouldn't have otherwise.

Jim Vlcek (vlcek@caf.mit.edu  uunet!mit-caf!vlcek)