🚀 go-pugleaf

From paul@batserver.cs.uq.oz (Paul Bailes):
> The answer is quite clear: a modern-style functional language [...]

    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.

    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...  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.  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.

    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...


    Bill Wolfe, wtwolfe@hubcap.clemson.edu