Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Re: Forth and Functional Languages
Keywords: Compilers are not perfect, and machines are not infinitely fast...
Message-ID: <1676@crete.cs.glasgow.ac.uk>
Date: 29 Sep 88 14:25:04 GMT
References: <8809092121.AA09902@jade.berkeley.edu> <1625@crete.cs.glasgow.ac.uk> <7122@well.UUCP> <1643@crete.cs.glasgow.ac.uk> <4889@juniper.uucp>
Reply-To: orr@cs.glasgow.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 79

In article <4889@juniper.uucp> olorin@juniper.UUCP (David Weinstein) writes:
>
>In article <1643@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes:
>No. Or I'll make it a challenge. Pick a high-level language, and a common CPU
>for which there are programmers working in assembly regularly. Now, chose a
>problem. While the HLL programmer may finish first, a good assembly language
>programmer will produce *much* more efficient code. Furthermore, conventional
>languages can't work in many areas (do you want to explain why you need 4 more
>inches of space on the board to hold all the libraries your compiler linked in
>along the way... :-)

*Much* more efficient?  This seems rather a strong statment.  Although
when programming in MLLs you can problably produce *somewhat* more
efficient to say only this is to present a very narrow perspective.
Firstly in HLLs you program closer to the problem area, so more thought
can go into things like algorithims and program layout.  This can in
some cases even lead to *much* more efficient HLL programs (because you
chose a better algorithim - I seem to remember mentioning this a while
ago though).  Yes I know that anything you can do in an HLL you can do
in an MLL, but in MLL programming (in my experience of it anyway) you
usually can't see the wood for the trees.  Of course a far more
important argument is that generally you can produce HLLs with far fewer
bugs (again because your program is closer to the problem domain), and
in my humble opinion a program that gives the right answer after an
hour, is much better than one that crashes after five minutes.
Furthermore a good optimising compiler can produce very good code
indeed.  Although it can't make some of the problem oriented
optimisations that can be made in an MLL (and often also in an HLL) they
can make other ones that would be tedious in the extreme for a human to
do (an example that immediately springs to mind is efficient register
usage.)

As to board space, don't blame me if you've got a rotten linker!  :^> I
guess the problem with the linker is that it was written in an MLL and
although it is faster than lightening, it was too dificult to put in
features like selective loading...  :^>

>The attitude, "If the program written in an HLL isn't fast enough then my
>compiler isn't good enough, and if my compiler is good enough but it's still
>too slow I'll buy a new machine", (which is a paraphrasing of a comment I
>found on comp.lang.misc a week or so ago) is one of the things that disturbs
>me most about CS departments (or at least the ones I've been in a position to
>observe). Quite simply...you can't really do that in the real world, with

Hmmh, you've got a point.  I take the acedemic view you outline above
(surprise, surprise!) and I think that this is a reasonable veiw for an
academic to take, since academic's job is to look to the future (when
there most certainly will be bigger faster and better computers about.)
But I accept that this cannot be the veiw taken in the "real" world.  If
you remember earlier I was saying that my favorite language was Miranda,
but that I didn't use it in my job, because it was too slow.  (That of
course doesn't mean that Miranda is no good, because there will come a
time when the computers are big and powerful enough to run Miranda)

>observe). Quite simply...you can't really do that in the real world, with
>finite resources. Upper management in many cases will find your programming
>time a more reasonable expense then replacing the computer you just got with
>a faster one (and compiler revisions are infrequent at best...and remove old
>bugs simply to replace them with a host of new bugs). I shudder when I think

I think that you have a cheek to talk about bugs!:^) You are advocating
a style of programmning that produces far more bugs than I have problems
with compilers.  Compiler bugs I agree are a real pain, but they can be
documented and got round.  Anyway, what are you suggesting, write your
compiler in MLL, and put in even more bugs?:^>

>bugs simply to replace them with a host of new bugs). I shudder when I think
>the CS students who *don't* work in the real world while pursuing a degree, 
>and face a dreadful shock when they get out of the ivory tower. 

Again you have a point, I think that a lot more practical stuff in CS
courses would be of great benefit.  But also of great benefit is to
expose students to "pure" programming techniques so that they know
whereabouts they are making compromises for the sake of efficiency.

>Dave Weinstein

Regards,
===Fraser