Path: utzoo!attcan!uunet!kddlab!ccut!ascgw!fgw!flab!ayumi!feldmark
From: feldmark@hanako.stars.flab.Fujitsu.JUNET
Newsgroups: comp.lang.misc
Subject: What makes a language "easy" to program in?
Message-ID: 
Date: 31 May 88 07:02:41 GMT
Sender: news@ayumi.stars.flab.fujitsu.JUNET
Distribution: comp
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan.
Lines: 58
Posted: Tue May 31 16:02:41 1988
Posting-Front-End: GNU Emacs 18.41.6 of Fri Feb 19 1988 on hanako (berkeley-unix)

The other day I was having a discussion about "what I would put into a
parallel processing computer language, if I were designing one".  We
were trying to quantify what makes certain programming languages "easy"
to program in.

We were discussing general MIMD parallel processing, and I am a
consummate C programmer, but wouldn't dream of proposing a sequential
programming language that is "hacked" to provide parallelism.  It has
to be an inherently parallel or data flow type of language.  In
particular, we were discussing features of C, GHC (a concurrent
Prolog-ish logic programming language), and Smalltalk. GHC is
inherently parallel resulting in many data flow-like features.  I have
done a little programming in GHC here at work (but nothing really
big), and started learning Smalltalk about a week ago, so don't have a
lot of experience to base comparisons on.  (But I know that I was
constantly wishing I could put loops and arrays into my GHC programs.)
The points I could come up with maybe a bit generalized and obvious,
but...

To me right now, sequential style programming is just easier than
programming in a language that is inherently parallel.  Too many
things to keep track of. In GHC for example, goals comprising the body
of an predicate may essentially be executed in a random order.  So one
has to be very careful to be sure his program works regardless of the
order of execution.  It is much easier to program, given a specific
order (sequential) to depend on.  (But obviously bad for parallel
processing.)  There is also some advantage in my being able to program
well with sequential language constructs, because I can ALREADY do it and know
instinctively how to attack a problem.  It was also suggested by an
experienced GHC programmer that if he came back a year after writing a
complex GHC program and a complex C program to add features, it would take
considerably longer time to understand the GHC program than the C
program.  (Yes, even with sufficient comments. :-)

From the little I know of Smalltalk and object oriented programming in
general it seems that the best features are the modularity that is
imposed by the language itself and lack of typing.  Modularity is
definitely not mandatory in GHC or C.  But then I have also heard that
really large systems get painful to deal with even in Smalltalk. (Any
comments on this?)

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