Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!stanford.edu!neon.Stanford.EDU!flamingo.Stanford.EDU!espie
From: espie@flamingo.Stanford.EDU (Marc Espie)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Functional Programming (Re: Good programmers and assembly language)
Message-ID: <1991Apr8.005252.8503@neon.Stanford.EDU>
Date: 8 Apr 91 00:52:52 GMT
References: <7214@harrier.ukc.ac.uk> <1523@tronsbox.xei.com> <7235@harrier.ukc.ac.uk>
Sender: news@neon.Stanford.EDU (USENET News System)
Organization: LIENS, ENS, 45 rue d'Ulm, Paris (France)
Lines: 110

In article <7235@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes:
>In article <1523@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes:
>>In article <7214@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes:
>>|In Miranda all you need is three lines:
>>|
>>|qsort :: [*] -> [*]
>>|qsort [] = []
>>|qsort (a:X) = qsort [b|b<-X; b<=a] ++ [a] ++ qsort [b|b<-X; b>a] 
>>|
>
>>	If learning a high-level language means putting up with gibberish like
>>THAT, I think I'll switch to raw hex instead.

Well, Miranda is not incredibly readable. How about a nice factorial function ?
fact(n) = n * fact(n-1)
fact(0) = 1
There are languages around where you can specify it that way, and it will run.
It won't even be especially slower than C or assembler...
There are also languages where you can DO things you wouldn't even think of
doing in assembler or C. Ever heard of lazy languages ? You can define lots
of stuff, the language won't even bother about evaluating them... unless it
NEEDS too. For instance, you can define the list of ALL the primes number,
and do computations with it...

The fact is, assembly programmers who don't give a damn about C or higher
level language (C is still pretty much low level compared to recent 
developpement) haven't usually enough background to know why other languages
do exist. Granted, it is possible to write games in assembly language, it may
even be the choice method on the amiga, but that does not mean I'd try to
write a very intricate scientific project with it...
Other people in other communities have the same attitude about Fortran.
Intellectual lazyness... not wanting to learn anything new because they
are content with what they have.
>
>I think you've made a very hasty comment there. You are obviously put
>off by the notation and confused by the totally different approach to
>imperative programming languages such as C that most people are
>used to.
>
>But if you know how the quick sort algorithm works (you'll find this in
>any decent algorithms book) you should be able to understand those
>three lines if you think about it. They're almost a specification of
>quick sort rather than an implementation !  Familiarity with set and
>function notation in Mathematics is also very useful. Just to help you
>along if you want to understand it better:
>
>[*] denotes a list of items of the same arbitrary type
>[]  denotes the empty list
>[a] denotes the list containing only the item a
>[b|condition; condition; ... ]  (called a List Comprehension) denotes
>    the list of all b's which satisfy the ensuing conditions
>++  is the operator which concatenates lists
>h:T is used for pattern matching on lists. It will match any non-empty
>    list, and place the first element of the list in h (head), the remaining
>    list in T (tail) (In the above, a:X was used)
>
>The third line is obviously using recursion. In my opinion this line
>captures the essence of the quick sort algorithm very elegantly. Again
>think of how many PASCAL or C statements you'd need to implement
>quicksort (more the so for assembler).
>
Maybe quicksort is not always the right algorithm... it almost never is,
in fact. The thing is, it won't take you much longer to rewrite your
sort as a heapsort or anything else.
>I can assure you that languages such as Miranda, Hope and ML, do
>provide significant advantages over traditional programming languages.
>Their authors have analyzed the shortcomings of traditional languages
>and written new ones to overcome them. A very good introduction to
>such languages is given in "An Introduction to Functional Programming"
>by Bird & Wadler (published by Prentice-Hall) for anyone who's interested.
>Increasingly more universities are including functional programming in
>their undergraduate courses - there are even opinions that a functional
>language should replace Pascal as the traditional first language taught
>at university.
>
Anyway, Pascal is not a real world language. Niklaus Wirth advocated it
as a language suitable for education. This is no wonder some people switch
to assembler after an exposure to Pascal...

>Now all I want is a decent implementation of a functional language
>for the Amiga! Did I hear anyone say they'd done a version of ML ?
>
>Michael Rizzo

As advanced bibliography, the Peyton-Jones' Compiling Functional Languages
gives a good idea of how incredibly much ``higher-level'' some functional
languages can be. Good compilers are able to catch things it would take 
forever for a gifted assembly-programmer it would take to write correctly.
There seems to be a misconception creeping up that all you need to program
is a machine and some brains. That's wrong. There are also a lot of researchers
doing work. Most of it is not used in practice, but eventually their work
comes to get implemented inside compilers or libraries function. Being one
such researcher myself, I've got a good idea of the time spent devising some
algorithms or some compilers. If you add up everything, you end up with
hundred of man-years behind a reasonable C compiler... just look where 
the algorithms come from, then look at the references, then look at all the
trials and errors.

I'm just thinking right now of the work I'm doing, the algorithms I implement.
They are already mind-taxing is simple ideas on sheets of paper, how would I
ever be able to code them down in assembler ? It's already difficult enough
in C that I would happily change to something better where it not for
practical reasons...

Matt Dillon said something very similar a while ago, about the fact that
you also have to read books to be a good programmer (so long for
the ``10 pages of the Hardware manual are enough for me'' idea).
A pity I can't find back his posting...
--
	Marc (espie@flamingo.stanford.edu)