Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: He's not the only one at it again!
Message-ID: <2400@l.cc.purdue.edu>
Date: 25 Jul 90 13:45:55 GMT
References: <1990Jul21.004616.649@Stardent.COM> <388@e2big.mko.dec.com> <1990Jul23.231717.2766@cs.UAlberta.CA>
Organization: Purdue University Statistics Department
Lines: 73

In article <1990Jul23.231717.2766@cs.UAlberta.CA>, cdshaw@cs.UAlberta.CA (Chris Shaw) writes:
> In article gillett@ceomax.dec.com (Christopher Gillett) writes:
> >In article peter@ficc.ferranti.com (Peter da Silva) writes:
> >>In article gillett@ceomax.dec.com (Christopher Gillett) writes:
> >>> Aha! Lets presume for a moment that you are truly a computer scientist,
> >>> and that you buy into all the stuff that computer "science" teaches.
> >>
> >>Which computer "science"? The real one, or the straw man Bruce Karsh and
> >>you keep bringing up.
> >
> >That's exactly my point! IMHO, there's really no such thing as
> >"Computer Science". 
> 
> What is your point, that you give straw man arguments, or that you have this
> well-known opinion?
> 
> >Physics, chemistry, biology, mathematics, are all real sciences.
> 
> Bull. Mathematic is not a "science". It is rigorous philosophy. Mathematics
> intends to show things which are true regardless of what observations can be
> made in the real world. In Kantian terms, Mathematics has essence,
> but no existence.

Mathematics is pure grammar, but not philosophy of any kind.  I disagree 
about the existence part, however.  Computer science is the same sort of
thing.

But even pure grammar can have results on such things as how fast a program
can do something, given assumptions (these come from the hardware and the
nature of the problem) about how the components work.  Discussions about
how much effort is required to compute a given function to a given accuracy
predate the existence of non-human computers.

			................................

>                       It was a pretty good observation made by whoever in the
> 50's that you could write programs with a consistent programmer interface,
> but which ran on different machines. Hence FORTRAN.

Not according to the facts.  The only language I know of in any remotely
wide usage at the time Fortran was created was (ugh) COBOL.  Fortran was
created specifically for casual programming on the IBM 704.  It was only
after it was produced that it was observed that it could be used on other
machines.  The extremely poor attempt to produce a machine-independent 
computational language ALGOL was the followup.

> The benefits of portability are clear, and there is no need to restate them.
> However, some people beleive that portability is not important, because they
> will never have to port their program to a new machine type. However, it's
> a tiny minority of people out there who don't get bitten by unportability
> at some point.

Full portability is likely to be very costly.  It is frequently possible to
do a fair job by providing for extensibility in the language.  There have
been a few languages which allow adding types, including some Fortrans. 
C++ does it in a somewhat clumsy way.  The original Fortran allowed open
function calls, but not other open subroutines.  Inlining may or may not
achieve this.  There are many features of Fortran determined by the architecture
of the target machine, and very limiting, as was the idea that Fortran was not
for the construction of system libraries (at least when it was produced).  Other
languages, like C, also show the influence of the target machines.

It is very difficult to remove limitations of a language after the language is
specified.  It is very difficult to overcome the weaknesses in hardware after
the design is set.  The presence or absence of a single hardware instruction
can provide a large factor in the comparison of algorithms.  A change in 
relative timings of instructions can greatly modify the choice of algorithms.
An intelligent computer scientist or machine designer will take all this into
account, and will also recognize that it is easy to miss important things.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)