carriero@YALE.EDU (Nicholas Carriero) (05/10/89)
Prof. Kale writes
It may be argued that tuple-space is conceptually easier because,
say, the programmers do not have to think about who the recepient of
a message is. However, in most (or at least some?) cases, the
programmers ALREADY know that. Linda simply forbids them from
stating it!
Not true (As Moshe Braner has pointed out). If A wants to send to B,
A writes out("B",...) and B executes in("B",...).
...There are currently about 6-7 types of such psueo-global
variable types (**). Among them is a type called dynamic table.
Variables of this type have functionality that subsumes the
functionality of tuple-spaces. (Take my word for it, for now, for
the sake of argument)
Given the above, we're not inclined to take you word for it.
Can you store processes as entries in your dynamic tables? (Processes
that turn into passive data entries when they're done--)
So, compared to "specific sharing" in chare kernel, "generative
communication" of Linda is potentially a source of inefficieny, and
(more important) is not conceptually better either.
Speculative arguments about Linda's efficiency are irrelevant; eight
years ago they made sense, but today there are a large number of
efficient implementations. (We've made this point recently, so we
won't elaborate here). As to your opinion that Linda "is not
conceptually better", your argument amounts to the following: "if
tuple space is good, tuple space plus 5.5 other things is even
better". But unfortunately, making simple things complicated is not a
cost-free exercise. You burden the programmer with a more complex
model to master, the program-reader with more complicated sources and
the implementer with a harder optimization problem. We choose to
program in languages that provide optimized support for a few simple
tools and then let us build what we need. But you pay your money &
you take your choice.
Nick & Dave