Andrew C. Greenberg wrote:
>
> I fear this debate seems to be taking an odd twist into irrelevancy.
> While it may be true (indeed unsurprising) that human cognition can be
> modelled most appropriately using concurrency; indeed of a promiscuous
> nature, I do not see how this indicates or counterindicates that a
> concurrent model is the best model for human cognition to specify the
> execution of system.
>

I agree (and I started this subthread by writing "As an aside ... Minsky ...
Society Theory of Mind ..." and placed that in square brackets). But I can
see two ways it might be relevant:

1. One reason to give kids (and others) programming languages is to give
them tools to think with. And one important thing to think about is how the
mind works. If you read Descarte you see he (and many of his contemporaries)
used the metaphor of a clockwork to understand the mind. If you read Freud
you see he used a pneumatic model (presure builds up that must be released,
etc.). Some recent posts to this discussion used the model of a collection
of sequential threads to understand the mind. So if we think that one better
understands the mind with a good concurrent computation model then all else
being equal we should prefer languages based upon such models.

2. If you want to use a language to make AI programs then it is relevant.
And I like the idea of having kids try to make simple AI programs.

[clip]
>
> This is not to say that promiscuous determinacy doesn't also add
> complexity -- it most certainly does.  An example as trivial as the swap
> operation of two values x and y, which is invariably modelled using a
> temporary variable
>
> t := x; x := y; y := t
>
> introduces complexity unrelated to the problem.  Indeed, Edsger Dijkstra
> emphasized the problem of overdetermining code, favoring therefor the
> language construct of the concurrent assignment, so swap can be
> indicated thus:
>
> x,y := y,x
>
> leaving the more detailed sequencing to the "system" to sort out.  The
> problem here is that such nondetermincy is well-constrained and easily
> implemented in worst case.  The sequencing and protection of shared
> resources in concurrent programs is far more subtle and problematic.
>
> My point is that while it is apparent that overdetermining code
> sequentially often introduces levels of detail that precludes more
> elegant expression of correct code, and sometimes distracts from best
> ways to articulate the code, so, too, does expression of concurrency
> introduce subtle unstated bugs and requires stating degrees of
> sequencing, which are often harder to express than merely specifying the
> sequencing in all its gory detail.
>

I'll agree with you and Dijkstra about overdetermining code (and I rarely
agree with Dijkstra). Let's consider a simple case of what I think you are
saying. Suppose you have a language where if you write "A, B" then A and B
are run concurrently while if you write "A; B" they run sequentially. (If I
remember right this is how Parlog from Imperial College worked.) Now suppose
that A and B can't interfere with each other. The principal of expressing
only necessary constraints (i.e. avoiding overdetermining code) would say
you then write "A, B".

But the problem here is that every time you write 2 lines of code you have
to think "OK, do they interact?" and then use comma or semi-colon as
appropriate. This is a cognitive burden. And the consequences for the two
kinds of mistakes are very different. If you think they interact and they
don't, then the code will still run - it is just overdetermined (well,
actually you might have introduced deadlock). If you think they don't
interact and they do, then you might have introduced a subtle hard-to-find
bug.

The solution to this that I prefer is to eliminate the semi-colon and only
support concurrent composition. And then design the language so the
consequences of pervasive concurrency are acceptable. I think this works in
languages in which all shared state is encapsulated in objects, where
threads and objects are one-to-one, and where all messages are asynchronous.

Best,

-ken kahn ( www.toontalk.com )