In Pd (the third example), the fundamental transaction goes in the direction favored by the performer. This idea goes back to Max, and that orientation might have been the most important single reason that Max and Pd are in wide use today. But as noted before [DH93] [Puc02a], the message-sending paradigm does not fundamentally lend itself well to storing and retrieving data. One is almost forced to set data aside in containers--databases, essentially--and to use a coterie of accessor objects to store and retrieve data under real-time, message-passing control.
Max's approach to data is both simple and evasive: special data-container objects such as table, qlist, etc. are provided; the data are essentially hoarded inside the container objects, and for each kind of container object a particular ad-hoc approach is taken to its storage, its editing, and its interfacing with the rest of the patch.
Retrieval (the great majority of database transactions!) is the worst fit with Max because messages don't have return values; the retrieved data must be sent as a separate return message. This leads to much misery for Max users.
Pd faithfully recreates the data-storage paradigms of Max, but in addition the design of Pd includes a more advanced paradigm that might eventually replace the Max one.
The original, defining idea behind Pd was to remove the barrier between event-driven real-time computation (as in Max-style message passing) and data (as in points of an array or notes in a score). In Pd the two (object boxes and data structures) can easily coexist in a single window. This promiscuity, however, does not in itself make the functional objects and the data intimately connected. In fact, in the present design, data access still has to be done through a suite of accessor objects. It is far from certain that Pd will, in the end, relieve the Max user's misery.