OOPv2: [Was: Message passing syntax for objects]

Mark Janssen dreamingforward at gmail.com
Wed Mar 20 05:46:32 CET 2013


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130319/a646c80f/attachment.html>


More information about the Python-list mailing list