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)