Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!markv
From: markv@phoenix.Princeton.EDU (Mark T Vandewettering)
Newsgroups: comp.lang.misc
Subject: Re: Which language to teach first?
Message-ID: <9970@phoenix.Princeton.EDU>
Date: 17 Aug 89 14:20:56 GMT
References: <1304@batserver.cs.uq.oz> <6264@hubcap.clemson.edu>
Reply-To: markv@phoenix.Princeton.EDU (Mark T Vandewettering)
Organization: Princeton University, NJ
Lines: 110

In article <6264@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From paul@batserver.cs.uq.oz (Paul Bailes):
>> The answer is quite clear: a modern-style functional language [...]

	I would heartily agree, with a caveat.  It is my belief that 
	functional programming languages are both powerful and
	reasonably efficient, and permit a treatment of program 
	development which is more rigorous than that generally taught
	with more imperative languages.  Witness the success of the 
	Scheme language (not a pure functional language admittedly)
	which is largely due to the excellect text by Abelson and
	Sussman, which is probably the single best text on computer
	science that I have seen.

	The one caveat is the relative lack of a good, public domain
	(or nearly so) implementation of a language like Miranda.
	Until such an implementation is available, we cannot make
	the learning experience practical for students.

>    Since the ACM Task Force on the Core of Computer Science has
>    specified parallel programming as one of the 11 major topics
>    to be covered in an introductory course, the language used
>    should be one in which parallel programming is supported.

	However, the parallelism that you desire is an inherent part of
	functional programming.  Because of the lack of side effects,
	the only constraints placed on evaluation order are the natural
	data dependancies.  It is precisely this property which makes
	functional programming languages MORE amenable to parallelism
	than traditional imperative languages.
	
>    Quoting David M. Harland (Concurrency and Programming Languages, 1986):
>
>       The history-sensitivity of the imperative languages contrasts
>       with the total inability of functional systems to handle
>       interactions with the outside world...
	
	Partial agreement on this count, it is the strongest argument 
	against functional programming.  It is an area of active
	research however, with some recent advances.  It is also
	interesting to note that many computer programs DO act as
	"functions", they take input and churn and generate output.

>	It is interesting
>       to ponder what would happen if processes were made explicit
>       in functional languages.  With the introduction of arbitrary
>       interactions, sequentiality would return and this would remove
>       the basis of their traditional implementation.  

	Adding explicit processes doesn't mean adding interactions.
	MultiLisp for example, has explicit processes which are in the
	form of futures or promises.  These do not change the semantics
	of the program in the slightest.  If you are talking about
	adding message passing or some such nonsense, the point is moot:
	the language would cease to be functional.

>       There is far
>       more to the issue than the fashionable 'single-assignment'
>       approach would have us believe.  Functional languages _rely_ 
>       upon the fact that they are not history-sensitive to evaluate 
>       expressions in parallel, and thereby are claimed to be inherently 
>       parallel languages.  This is not so.  They are not sequential, 
>       but this is far from being parallel.  The only parallelism they 
>       offer is hidden in their implementation; it is implicit.  A truly 
>       parallel language would make its concurrency explicit, and allow 
>       arbitrary computation over the agents of parallelism.  Far from the
>       applicative languages providing the most natural evolutionary path 
>       for future 'good' programming systems, they are, as currently defined,
>       fatally flawed.

	I disagree totally, as do many others.  In order to make
	parallelism work, it is REQUIRED to be implicit.  Consider the 
	Actor model of Hewitt.  It requires the explicit coordination of
	large numbers of individual computational agents.   Because
	their computation is history sensitive, the action of the
	program is some function of the program state (the state of all
	the subactors), each of which is a function of ALL of the
	message traffic done to date.  What is lacking in the Actor
	model (and in every other model which uses explicit parallelism
	and history sensitive behavior) is a formal basis to reason
	about the meaning of programs.

	The only way to manage the complexity of programming a network
	of thousands of processors is to let the computer take up the
	slack.  We should let the computer make choices about
	partitioning and scheduling, and leave it to the programmer to 
	develop parallel ALGORITHMS to accomplish the task at hand.
	Techniques such as strictness analysis, compile time reference 
	counting, and program transformations can be used to detect and
	exploit potential parallelism.


>    But don't worry; Ada will be quite happy to take up the slack while 
>    you functional programming types run right back to the drawing board...
	
	Excuse me, but I think we will continue our steady progress
	thank you.

	For an interesting look into the possibilities of functional 
	programming and parallelism, try
	
		"Functional Programming on Loosely Coupled Multiprocessors", 
		Kelly, MIT Press, 1989.

	Not the absolute best book, but chock full of further references
	to guide the misinformed (1/2 :-). 

>    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Mark VandeWettering (markv@acm.princeton.edu)