I don’t think the features of the theoretical system were particularly relevant. I can see several reasons why this wouldn’t take off, and no reasons why it would. For example:
Objects are assumed to communicate through message passing and to interact according to the rules of actor semantics [3,4], which can be enforced at either the language or operating system level. These rules formalize the notion of distinct, asynchronous, interacting entities, and hence are appropriate for describing participants in computational markets.
This part raises a few red flags. We were pretty terrible at asynchronous anything in 2001; the only successful example I know of is communication systems running Erlang, and Erlang is inefficient at math so cost functions would have had a lot of overhead. Further, in the meantime a lot of development effort was put into exploring alternatives to the model he proposes, which we see now in things like practical Haskell and newer languages like Rust or Julia.
Further, we’ve gotten quite good at getting the value such a system proposes, we just write programs that manage the resources. For example, I do tech support for Hadoop, the central concept of which is adding trade-offs between storage and compute, and Google used Deepmind to manage energy usage in its datacenters. Cloud computing is basically Agoric computing at the application level.
In order for Agoric computing to be popular, there would need to be clear benefits to a lot of stakeholders that would exceed the costs of doing a complete re-write of everything. In a nutshell, it looks to me like Drexler was suggesting we should re-write all software under a market paradigm when we can get most of the same value by writing software under the current—or additional—paradigm(s) and just adding a few programs which optimize efficiency and provide direct trade-offs.
An alternative, more abstract way of thinking about the problem: it is hard to create a market where there aren’t currently any transactions. Until quite recently, transactions were only located where the software was sold and where it was written.
I think the effort would have been more successful if the question was not “how do we make software to use market transactions” but rather “how do we extend market transactions into how software works” because then it would be clear we need to approach it from one end or the other: in order to get software to use transactions we would need to make software production transactions more granular or software consumption transactions more granular. The current trend is firmly on the latter side.
I don’t think the features of the theoretical system were particularly relevant. I can see several reasons why this wouldn’t take off, and no reasons why it would. For example:
This part raises a few red flags. We were pretty terrible at asynchronous anything in 2001; the only successful example I know of is communication systems running Erlang, and Erlang is inefficient at math so cost functions would have had a lot of overhead. Further, in the meantime a lot of development effort was put into exploring alternatives to the model he proposes, which we see now in things like practical Haskell and newer languages like Rust or Julia.
Further, we’ve gotten quite good at getting the value such a system proposes, we just write programs that manage the resources. For example, I do tech support for Hadoop, the central concept of which is adding trade-offs between storage and compute, and Google used Deepmind to manage energy usage in its datacenters. Cloud computing is basically Agoric computing at the application level.
In order for Agoric computing to be popular, there would need to be clear benefits to a lot of stakeholders that would exceed the costs of doing a complete re-write of everything. In a nutshell, it looks to me like Drexler was suggesting we should re-write all software under a market paradigm when we can get most of the same value by writing software under the current—or additional—paradigm(s) and just adding a few programs which optimize efficiency and provide direct trade-offs.
An alternative, more abstract way of thinking about the problem: it is hard to create a market where there aren’t currently any transactions. Until quite recently, transactions were only located where the software was sold and where it was written.
I think the effort would have been more successful if the question was not “how do we make software to use market transactions” but rather “how do we extend market transactions into how software works” because then it would be clear we need to approach it from one end or the other: in order to get software to use transactions we would need to make software production transactions more granular or software consumption transactions more granular. The current trend is firmly on the latter side.