Toby Schachman <t...@alum.mit.edu> writes: > This half hour talk from Zed Shaw is making rounds, > https://vimeo.com/43380467 > > The first half is typical complaints about broken w3 standards and > processes. The second half is his own observations on the difficulties > of teaching OOP. He then suggests that OOP is an unnatural programming > paradigm and that the problems of the web stem from the problems of > OOP. > > My take: > > I agree with Zed that the dominant "OOP" view of reality no longer > serves us for creating the systems of the future. I imagine that this > will be a hard pill to swallow because we (programmers) have > internalized this way of looking at the world and it is hard to *see* > anything in the world that doesn't fit our patterns. > > The hint for me comes at 22 minutes in to the video. Zed mentions > OOP's mismatch with relational databases and its emphasis on > request-response modes of communication. Philosophically, OOP > encourages hierarchy. Its unidirectional references encourage trees. > Request-response encourages centralized control (the programmer has to > choose which object is "in charge"). Ted Nelson also complains about > hierarchical vs. relational topologies with respect to the web's > historical development, particularly unidirectional links.
This is wrong. Request-responses mode comes from the mapping of the notion of message sending to the low-level notion of calling a subroutine. Unidirectional references comes from the mapping of the notion of association to the low-level notion of pointer. But those mappings are not inherent of OOP, and aren't even necessarily promoted by a OO programming language. And even if they may seem at first natural with common OO programming languages, it's easy to avoid using them. For example, request-response is NOT the paradigm used in OpenStep (Cocoa) programming. For example, when a GUI object is edited, it may send a message to a controller object, but it does not send the new value. Instead, it sends itself, and let the controller ask for its new value later. Some languages implement message sending as an asynchronous operation natively. So it seems to me it's a case of taking the tree for the forest. > I've been reading (and rereading) Sutherland's 1963 Sketchpad thesis ( > http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-574.pdf ) and it > strikes me that philosophically it is founded on *relationships* > rather than *hierarchy*. Internally, references are always stored > bi-directionally. It presents the user with a conceptual model based > on creating constraints (i.e. relationships) between shapes. Indeed. > Chapter 7 has been particularly hard for me to grok because his > "recursive merging" has no good analogue in OOP inheritance strategies > as far as I know. Here he takes a structure A (a network of things and > their relationships) and merges them onto another structure B by > specifically associating certain things in A with things in B. This > operation creates new relationships in structure B, corresponding to > the analogous relationships in structure A. Inheritance by analogy. > > He claims to get quite a bit of leverage from this strategy. > > Toby > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
