Path: utzoo!attcan!uunet!oddjob!ncar!boulder!sunybcs!rutgers!columbia!cunixc!evan
From: evan@cunixc.columbia.edu (Evan Bigall)
Newsgroups: comp.lang.misc
Subject: Re: What makes a language "easy" to program in?
Message-ID: <711@cunixc.columbia.edu>
Date: 5 Jun 88 02:46:06 GMT
References: 
Reply-To: evan@cunixc.columbia.edu (Evan Bigall)
Distribution: comp
Organization: Columbia University
Lines: 44

>Maybe this all boils down to the pros and cons of sequential,
>functional, logic, and object oriented programming.  If this hasn't
>already been beaten to death at some time in the recent past, does
>anyone have any comments on what it really is that makes any of these
>"easy" (or hard) to program in?  Would loop macros in Prolog/GHC do
>the trick for me?  Can I incorporate sequential features into an
>inherently parallel language and still maintain a coherent language
>model?  Would I have a different feeling about it being "easier" to
>program in C than GHC or Smalltalk if I had learned a non-sequential,
>logic, or object-oriented programming language first?  Or is the only
>solution to just develop programming instincts for inherently parallel
>languages?
>
>Mark Feldman
>Fujitsu Laboratories Limited
>JAPAN: feldmark@hanako.stars.flab.fujitsu.junet
>USA:   feldmark%hanako.stars.flab.fujitsu.junet@uunet.uu.net

You have managed to skip one class of language (or at least one language) APL.

Many people would argue with me that APL is not easy to program in, but there
are a fair amount of people who use it (and swear by it) despite its glaring
flaws.  

APL is exactly what you have asked for, it is a sequential language that
supports inherent parallelism.  It has both fine grain parallelism in the 
form of all the vectors lying around and coarse grain parallelism in the form
"heavy data independant" nodes in the parse tree the can be efficently
scheduled for simultaneous execution.  For more on this idea see the papers by
Wai-Mee Ching of IBM Watson research describing his parallel/vector APL
compiler that takes advantage of theses things (I was heavily involved in the
code generation). 

While I am not suggesting we all switch to APL for parallel applications I do
think that it would be wise to take an objective look at the language and see
what might be worth stealing.  I have also noticed that an uncanny number of
papers on parallel languages seem to end up footnoting APL (Steeles C* paper
off the top of my head) maybe this is a hint?????

Evan

-- 
APL is a mistake, carried through to perfection.  It is the language of the
future for the programming techniques of the past.    -	Edsger Dijkstra