OOPv2: [Was: Message passing syntax for objects]

[Chris Rebert]

On Tue, Mar 19, 2013 at 9:46 PM, Mark Janssen <dreamingforward at gmail.com> wrote:
> Hopefully this won't be considered mail spam, but another quora answer that
> gets to the idea I'm after:  http://qr.ae/TMh7A
>
> Reposted here for those who don't have accounts:
>
> Q. Is it time for us to dump the OOP paradigm? If yes, what can replace it?
>
> When I was using C++ and Java, more of my time was spent fitting the problem
> to languages' OO paradigm than actually solving the problem.
> When I used Python, I found I was focusing on the problem more compared to
> other languages, but still that fitting aspect remained.
>
> I am looking for a language design perspective answer, where we can compare
> logic programming, functional, etc approaches and really see if the OOP
> still fits/necessary and do we need to evolve towards a better paradigm.
>
>
>
> A.  Yes.  OOP was the evolution of applying abstraction to a programming
> language, to the machine, having to remember that we used to deal very
> concretely with switches and bits.  Looking back, it can be seen to having
> gone too far.
>
> We don't need objects.  Programmers don't model physical things within the
> computer, except in the limited domain of (generally game) simulation.   It
> misinformed the paradigm in the wrong direction as many people found when
> programmers started making vast hierarchies of objects to try to categorize
> reality (Suburu inherits from Car inherits from Vehicle inherits from.....).
> So we went the wrong direction.
>
> What's to replace it?
>
> There was an interesting discussion on comp.lang.python started in 2004 by
> Mark Hahn about prototypes.  (See: Google Groups and Google Groups).   I
> think somehow it captures the idea pretty well.

(Actual links to the referenced discussion(s) would be appreciated.)

> Prototypes are a refactoring of all the explorations that OOP made, taking
> us back to our roots.  From the high-level abstraction of "objects" in the
> computer, back to the simple, understandable (C) structs and then encoding a
> way to shape or "template" data into a form that can take on abstract
> qualities which can then be used in a very general way.  The key difference?
> You're not way up in abstraction-land attempting to impose your personal
> taxonomy into the machine; instead, you're working from the common-ground of
> the machine and co-ordinating a object/data space into existence where other
> programmers can actually use them.   In other words, you're advancing the
> state-of-the-art of data structuring instead of applying some conceptual,
> hyper-personal abstraction into your code and onto the machine.
>
> The result?  Programmers can start making very simple, loosely-coupled,
> universal types and build upwards with other programmers into more and more
> complex, re-usable "mashups".
>
> This will create modularity, agility, and facilitate the evolution of a
> "universal programming space" as well as create the Open Source Culture that
> the Internet needs to re-start itself.

What a crock. Prototype-based languages are a somewhat interesting
alternative model, but IMO they are nowhere near as "game-changing" as
the post suggests. The elimination of classes simplifies the
MOP/metamodel a bit, but AFAICT doesn't improve much otherwise.
If prototypes were so revolutionary, they would presumably be faring
better in the marketplace of ideas (its promoters have been at it
since about as long as Python's have, apparently with less luck). If
you need evidence, look at JavaScript. It is, for better or worse,
among the most popular languages of our time and it is
prototype-based, but virtually no one chooses to make use of its
prototypical nature; almost all projects seem to end up consciously
re-implementing an approximation of traditional classes on top of the
prototype system (using one of several techniques, there seeming to be
no widespread agreement about which one is superior). Even prior to
JavaScript, in orthodox prototype-based languages, there is/was even a
concept of "traits" objects, which basically play much the same role
as classes in traditional OOP.

Also, I cannot for the life of me figure out how you made the abrupt
leap from message-passing to prototype-based OOP.
I echo Mark Lawrence's comment from your previous thread. +1 best
trolling so far this millennium. Have fun with your architecture
astronautics.

Regards,
Chris