Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site sunybcs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!sunybcs!lazarus
From: lazarus@sunybcs.UUCP (Daniel G. Winkowski)
Newsgroups: net.arch
Subject: Re: Yet another language (Occam) [Parallel Lang.]
Message-ID: <1436@sunybcs.UUCP>
Date: Mon, 1-Apr-85 15:51:35 EST
Article-I.D.: sunybcs.1436
Posted: Mon Apr  1 15:51:35 1985
Date-Received: Wed, 3-Apr-85 02:19:02 EST
References: <202@tekcbi.UUCP> <457@bonnie.UUCP> <7393@watrose.UUCP>
Organization: SUNY/Buffalo Computer Science
Lines: 45

> I read a very interesting article about a year ago by John Backus
> for his 1978 Turing Award Lecture in August '78 CACM.
> The article described the language FP in terms of higher-level abstrac-  
> tion and program provability, and although FP isn't exactly something you can 
> build device drivers with, it IS a useful first step in a new paradigm of the 
> type required to do useful parallel programming.

I have done a small amount of programming in FP (4.? BSD, implimented in
lisp) and have realized several things. 1) Though it runs god-awful slow
on a von Neumann architecture, it can easily be seen how it might take full
advantage of a parallel machine. 2) All languages seriously proposed for
parallel processing attempt to eliminate global side-effects by variables. FP 
accomplishes this very simply, it allows no variables! Aghast! Shock!
'Pure Lisp' also allows no global side-effects. Where as, von Neumann style
languages are programming by effect - sequential changes to a global
environment. [see also VAL - a Data Flow Language by Jack Dennis at MIT]

> One would probably be better off in learning a parallel language and using it
> on a parallel machine, than one would be in writing half a dozen C/FORTRAN
> post-processors to take advantage of your architecture.
> 
> The fundamental point to realize, I think, is that one can only adapt a tool
> so far (von Neumann-style languages) before you start having to create a
> new tool altogether.
> 
> Chris Shaw
> University of Waterloo

Agreed. Though, there are going to be many people who will want to port their
Fortran programs to this new machine (whichever it might be). Unfortunately,
because of this, I suspect that much more effort will go into the porting
problem, then into the language design problem. Or, at least, few will
bother to learn a new type of programming if they can continue using 
Fortran (though, there is no way in which a converted Fortran program will
be anywhere near as efficient as a program writen with parallel considerations
in mind).

=-=
Today we live in the future,
Tomorrow we'll live for the moment,
But, pray we never live in the past.
--------------
Dan Winkowski @ SUNY Buffalo Computer Science (716-636-2879)
UUCP:	..![bbncca,decvax,dual,rocksanne,watmath]!sunybcs!lazarus
CSNET:	lazarus@Buffalo.CSNET     ARPA:	lazarus%buffalo@CSNET-RELAY