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