Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!mcsun!ukc!harrier.ukc.ac.uk!mr3
From: mr3@ukc.ac.uk (M.Rizzo)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Functional Programming (Re: Good programmers and assembly language)
Message-ID: <7256@harrier.ukc.ac.uk>
Date: 10 Apr 91 19:47:11 GMT
References: <1523@tronsbox.xei.com> <7235@harrier.ukc.ac.uk> <1529@tronsbox.xei.com>
Reply-To: mr3@ukc.ac.uk (M.Rizzo)
Followup-To: comp.misc
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 96

In article <1529@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes:
>	That's not a hasty comment; that's one based on all the code I've seen
>from such wonderful languages as C, C++ and SmallTalk that look like line noise.
>I'd rather learn assembly than spend my life pondering strings of non-
>alphanumeric symbols.

Is this some kind of a joke or what ?  Do you honestly believe that
the thousands of people using the above-mentioned languages are a
bunch of idiots and you are some supreme programmer because you use
assembler ?

Did you ever try to learn one of the above languages properly before
making up your mind ? (By properly I mean using a language for at
least three months and working on exercises and at least a small project,
all with the help of at least one decent book). "Seeing code" as you
put it is far from being enough.

>|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).
>
>	Don't care how many lines it takes.

Less lines = less redundancy & more conciseness
The less code and unneccessary details you have, the easier it is
to figure out what is going on. An assembler listing is full of
unimportant details as far as an algorithm is concerned. An
AVERAGE Miranda programmer could easily recognize a quicksort in
Miranda in a few seconds. An EXPERT assembler programmer would take
minutes to recognize a quicksort written in assembler (ignoring
helpful identifiers in both cases of course).

>If there was a language with the
>power of C or assembler and the readability of Cobol, I'd marry it.

Readability of Cobol ?  What a joke ! Readability does not mean using
long English sentences. Cobol is horrible to look at - its all
cluttered and has no parameter passing mechanism. I'd like to see
how readable quicksort would be in COBOL - it doesn't even allow
recursion so you'll have to manage a stack as well, and all this
using global variables - what a mess!

The syntax of a language isn't the only factor when it comes to
readability. The features provided by the language are 
important factors as well e.g. local environments, apart from
being important for information hiding, make a program more
readable because the variables are declared close to where they
are used and not hundreds of lines further up in some global
DATA DIVISION or whatever COBOL calls it.

>As it
>stands, anything I write other than rexx scripts gets either flow charted or
>psudo-coded first, and THEN I worry about the assembler code.  It'd be 
>pointless for me to go through all that and then put all the real code on 
>three lines.  

No it wouldn't be pointless - it would save you a lot of time and
would allow you to try out your program as quickly as possible
without having to think about all the niggly details of assembler.
Gee - it seems that you ENJOY making work MORE TEDIOUS for yourself !

>|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.
>
>	The book review collumn in the current Byte covers some books that
>take the opposite stance.

Don't have the latest BYTE yet (I assume you're referring to April) so
I can't comment. However I'm pretty sure these books don't say anything
like you're saying about high-level languages.

>dfrancis@tronsbox.xei.com   ...uunet!tronsbox!dfrancis     GEnie: D.HEFFERNAN1
>------------------------------------------------------------------------------
>"Using C will definitely cut your life expectancy by 10 years or more."
>	--Carl Sassenrath, GURU'S GUIDE TO THE COMMODORE AMIGA #1

Gee - if that's true I wonder how assembler programmers manage to live
past 30 :-)

Sorry, but as far as I'm concerned, you are living proof that assembler
does not separate the men from the boys. Why don't you try reading a
few good books like Grady Booch's "Object-Oriented Design" which will
give you solid examples and reasoning about the advantages of OOP
languages like C++ and Smalltalk. Follow-ups to comp.misc for
those interested in continuing this thread - I'm not :-)

Michael Rizzo