Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!ames!decwrl!petunia!polyslo!jdudeck
From: jdudeck@polyslo.CalPoly.EDU (John R. Dudeck)
Newsgroups: comp.lang.misc
Subject: Re: GOTO vs. pointer vs. assignment
Message-ID: <260adcad.4abe@polyslo.CalPoly.EDU>
Date: 24 Mar 90 02:34:21 GMT
References: <5200059@m.cs.uiuc.edu> <14290@lambda.UUCP>
Reply-To: jdudeck@polyslo.CalPoly.EDU (John R. Dudeck)
Organization: Cal Poly State University -- San Luis Obispo
Lines: 58


In article <14290@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>> This would lead one to 
>> conclude that any imperative language is "dangerous", whether 
>> it has pointers or not.  
>
>It not only _would_ lead to such a conclusion - it has (past tense).
>What do you think all the functional language advocates are on
>about?  Indeed, there is a sense in which assignment leads to 
>some very complicated semantic issues which are completely avoided
>in functional languages.  Fortunately for most of us, people tend
>to have an intuitive understanding of these semantic problems that
>makes concern about them somewhat less important.  The same goes
>for GOTO (at least to some extent).  In my opinion, the problem
>is worst for pointers than for either of the other two (people
>_don't_ seem to understand pointers - intuitively or otherwise).

So at each level of program language evolution we have something "considered
harmful":

    FORTRAN et al -  goto
    C -  undisciplined pointers
    Pascal, Modula2, Ada -  disciplined pointers
    Everything except ML? -  assignment

Where is this going to end?  And what is going to be considered
harmful about the functional languages?  I would like to suggest:

    Functional languages -  abstract beyond human comprehension :^)

I seem to remember in the rationale for Ada something to the effect that
it is advantageous from the standpoint of program understanding for things
to be explicitly structured, where the structure is laid out in language
constructs in the code, and is static.  It seems to me that there is a
benefit in assignment--it nails down a piece of data to a static structure
so that the programmer has a chance to look at it and consider its role
in the program.

I have only looked at ML a couple times (one assignment for a languages
course).  Personally I find it difficult to grasp.  It requires a strong
mathematical background, as far as I can tell...  I have done some stuff
in Lisp, and that is what I had to fall back on to do anything in ML.
The pattern-matching aspects of ML seemed to me especially hard to
relate to.  However, I am sure that if I applied myself as much to learn
ML as I have to learn and master C, I would do fine with ML.

When I try to view this subject objectively, I see that there are good
elements in each paradigm, and a lot of the reasons given why certain
constructs are considered harmful come from theories of psychology that
relate to a programmer's presumed ability or lack of ability to grasp
a problem and develop its solution.

They can do all the studies they want, but that doesn't change a given
programmer's ability to do well at applying a language to solve a problem.
It all boils down to the effort required to excel at anything.  The
help that one gets from the tools is important, but I don't think that
it can be said that the "safeness" of a language is the most important
issue.

-- 
John Dudeck                           "You want to read the code closely..." 
jdudeck@Polyslo.CalPoly.Edu             -- C. Staley, in OS course, teaching 
ESL: 62013975 Tel: 805-545-9549          Tanenbaum's MINIX operating system.