It's better to think of tuple spaces as a concurrency / communications model than an implementation. So it's more like "the actor model" rather than Erlang's or Java/Akka's specific implementation of it. It's more about "if we had this type of system with these constraints and these features, abstracting away these details, what would we gain or lose?". You're right that in the end a good or bad implementation can make or break things (take a look at this paper: https://arxiv.org/abs/1612.02979), but that's not the point, at least with the original paper.
The interesting thoughts from the paper as far as I can see were: 1) Tuple spaces are programming language or architecture or program independent, and vastly different programs can communicate with each other 2) You don't communicate directly to other agents by address, you write to a topic and read from a topic, which is a form of decoupling producers and consumers 3) The "block when nothing to read in this topic" idea, which makes programming coordination SO easy. I guess it's a bit like unix pipes.
If tuple spaces don't seem that interesting and novel, it's probably because of the benefit of hindsight and that a lot of these ideas are so subsumed into the tools of today. I can't definitively make the claim that Linda is the cause of this, but I suspect it had some effect. I think the original author also had a lot of wacky ideas around "cyberspace" and all that, but that's another deal and I don't think it's why people find the Linda paper interesting now. The closest useful descendants of Linda to be seem to be modern Pub / Sub systems or coordination databases like RabbitMQ, Kafka, Zookeeper.
I can't run my service on a model, I have to run it on an implementation. When people try to abstract away the hard parts of the problems, it usually leads to bad results. For examples, SQL let's you express all sorts of interesting queries, very few of which are a wise idea to run thousands of time per second; ORMs make this even worse -- how data is stored and how data is queried really need to be determined in concert in order to make data storage and retrieval work, assuming you have sufficient data and query volumes to care -- if you've got only a few thousand pieces of data, it barely matters. That's not to say SQL isn't useful, or interesting, it's just not enough.
In this case, the mechanism seems too general -- if I want to read all the outstadning tuples with 2 as the second elememt, that's possible, but seems rather hard. If it's really about consuming tuples within a named channel, I want to know more about the expected or desired properties of distribution -- how is it determined which agent gets to consume a tuples when multiple request a matching tuple simultaneously, which tuple is consumed when many tuples exist that match. What guarantees are needed to ensure progress, what guarantees are hard to provide, what guarantees are useful, but not required etc. Is this the most basic abstraction for distribution, upon which other useful abstractions can be built -- or are there other underlying basic abstractions that are needed, are there useful abstractions which cannot be built upon this, etc.
> In this case, the mechanism seems too general -- if I want to read all the outstadning tuples with 2 as the second elememt, that's possible, but seems rather hard
How is this any different than an SQL query with 2 in the second column? Tuple spaces seem like a RDBMS with a more restricted query model.
The interesting thoughts from the paper as far as I can see were: 1) Tuple spaces are programming language or architecture or program independent, and vastly different programs can communicate with each other 2) You don't communicate directly to other agents by address, you write to a topic and read from a topic, which is a form of decoupling producers and consumers 3) The "block when nothing to read in this topic" idea, which makes programming coordination SO easy. I guess it's a bit like unix pipes.
If tuple spaces don't seem that interesting and novel, it's probably because of the benefit of hindsight and that a lot of these ideas are so subsumed into the tools of today. I can't definitively make the claim that Linda is the cause of this, but I suspect it had some effect. I think the original author also had a lot of wacky ideas around "cyberspace" and all that, but that's another deal and I don't think it's why people find the Linda paper interesting now. The closest useful descendants of Linda to be seem to be modern Pub / Sub systems or coordination databases like RabbitMQ, Kafka, Zookeeper.