[fonc] The Web Will Die When OOP Dies
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. 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. 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
Re: [fonc] The Web Will Die When OOP Dies
Toby Schachman 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
Re: [fonc] The Web Will Die When OOP Dies
Toby Schachman wrote: 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. To echo Pascal Bourguignon's sentiment, "this is all just wrong." First off, while I personally am not a big fan of OOP, seems to me that HyperCard was an existence proof that OOP is an incredibly natural programming paradigm, when it's packaged well. Re. problems of the web stemming from problems of OOP: Other than Java servelets, where is OOP much in evidence on the web? If anything, the web is a big implementation of the Actor paradigm. Web servers, by and large, listen for messages, and respond to incoming messages by spawning a process that generates a response, then terminates. Doesn't seem very object oriented to me - particularly when code takes the form of perl, or PHP. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
On Sat, Jun 9, 2012 at 8:48 PM, Pascal J. Bourguignon wrote: > 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. I agree that these are not necessary or intended implications of OOP. My comments used "OOP" to refer to the paradigm that I see used and implemented in common practice. Message passing does not necessitate a conceptual dependence on request-response communication. Yet most code I see in the wild uses this pattern. A hierarchy of control is set up. An object will request information from its subordinate objects, do some coordination, send commands back down, or report back to its superior. Centralized control seems to be the only way we can keep track of things. I rarely see an OO program where there is a "community" of objects who are all sending messages to each other and it's conceptually ambiguous which object is "in control" of the overall system's behavior. As for bidirectional references, I see them used for specialized subsystems (implemented by specialists) such as relational databases and publish-subscribe servers. But they tend to be tricky to set up in OOP settings. Yet, as I bring up in the Sketchpad remarks, I believe they have a lot of potential when they can be used as a fundamental primitive of a programming paradigm. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
While i agree with guy's bashing on HTTP, the second part of his talk is complete bullshit. He mentions a kind of 'signal processing' paradigm, but we already have it: message passing. Before i learned smalltalk, i was also thinking that OOP is about structures and hierarchies, inheritance.. and all this private/public/etc etc bullshit.. After i learned smalltalk , i know that OOP it is about message passing. Just it. Period. And no other implications: the hierarchies and structures is implementation specific, i.e. it is a way how an object handles the message, but it can be completely arbitrary. I think that indeed, it is a big industry's fault being unable to grasp simple and basic idea of message passing and replace it with horrible crutches with tons of additional concepts, which makes it hard for people to learn (and therefore be effective with OOP programming). -- Best regards, Igor Stasenko. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] The Web Will Die When OOP Dies
On 6/9/2012 9:28 PM, Igor Stasenko wrote:
While i agree with guy's bashing on HTTP,
the second part of his talk is complete bullshit.
IMO, he did raise some valid objections regarding JS and similar though
as well.
these are also yet more areas though where BS differs from JS: it uses
different semantics for "==" and "===" (in BS, "==" compares by value
for compatible types, and "===" compares values by identity).
granted, yes, bashing OO isn't really called for, or at least absent
making more specific criticisms.
for example, I am not necessarily a fan of Class/Instance OO or deeply
nested class hierarchies, but I really do like having "objects" to hold
things like fields and methods, but don't necessarily like it to be a
single form with a single point of definition, ...
would this mean I am "for" or "against" OO?...
I had before been accused of being anti-OO because I had asserted that,
rather than making deeply nested class hierarchies, a person could
instead use some interfaces.
the problem is partly that "OO" often means one thing for one person and
something different for someone else.
He mentions a kind of 'signal processing' paradigm,
but we already have it: message passing.
Before i learned smalltalk, i was also thinking that OOP is about
structures and hierarchies, inheritance.. and all this
private/public/etc etc bullshit..
After i learned smalltalk , i know that OOP it is about message
passing. Just it. Period.
And no other implications: the hierarchies and structures is
implementation specific, i.e.
it is a way how an object handles the message, but it can be
completely arbitrary.
I think that indeed, it is a big industry's fault being unable to
grasp simple and basic idea of message passing
and replace it with horrible crutches with tons of additional
concepts, which makes it hard
for people to learn (and therefore be effective with OOP programming).
yeah.
although a person may still implementing a lot of this for sake of
convention, partly because it is just sort of expected.
for example, does a language really need classes or instances (vs, say,
cloning or creating objects ex-nihilo)? not really.
then why have them? because people expect them; they can be a little
faster; and they provide a convenient way to define and answer the
question "is X a Y?", ...
I personally like having both sets of options though, so this is
basically what I have done.
meanwhile, I have spent several days on-off pondering the mystery of if
there is any good syntax (for a language with a vaguely C-like syntax),
to express the concept of "execute these statements in parallel and
continue when all are done".
practically, I could allow doing something like:
join( async{A}, async{B}, async{C} );
but this is ugly (and essentially abuses the usual meaning of "join").
meanwhile, something like:
do { A; B; C; } async;
would just be strange, and likely defy common sensibilities (namely, in
that the statements would not be executed sequentially, in contrast to
pretty much every other code block).
I was left also considering another possibly ugly option:
async![ A; B; C; ];
which just looks weird...
for example:
async![
{ sleep(1000); printf("A, "); };
{ sleep(2000); printf("B, "); };
{ sleep(3000); printf("C, "); }; ];
printf("Done\n");
would print "A, B, C, Done" with 1s delays before each letter.
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
