Re: Message passing syntax for objects | OOPv2

Discussion in 'Python' started by Mark Janssen, Apr 12, 2013.

  1. Mark Janssen

    Mark Janssen Guest

    Okay peeps, I'm re-opening this thread, because despite being hijacked
    by naysayers, the merit of the underlying idea I think still has not
    been communicated or perceived adequately. As a personal request from
    the BDFL, which I begrudge him for, I've removed the thread from
    python-ideas. If you want to tail him and ignore it fine, but I will
    be addressing the naysayers one-by-one and (since no one was willing
    to do a modicum of interference for me) presumably by myself. For
    reference of how this topic began, see http://qr.ae/TM1Vb and
    http://qr.ae/TMh7A which were questions from the programming community
    not astroturfed nor sockpuppeted by/for me. For the underlying itch
    being scratched which motivates this whole thread, see
    http://qr.ae/TM1Vb. But basically, I'm proposing a programming
    language *synthesis* and unification of the object-oriented and
    imperative language paradigms (two of the four paradigms recognized on
    wikipedia: http://en.wikipedia.org/wiki/Programming_paradigm) to
    create what I'm calling a "unified data ecosystem".

    I'm going to admit from the beginning that I am not deeply researched
    with the many varied explorations of the programming language
    *ontology*, BUT I have followed the main "trunk", if not gone out on
    every branch. I *will* say that I am degreed in Computer Engineering
    (PLU '92) and have a fairly solid theoretical background in the art
    and the science of CS. Further, I will admit that I am not deeply
    experienced in application or Internet programming -- I have stayed on
    the outside watching those developments so that I can fulfill a vision
    I have of what the Internet can be (a world-changing technology to
    make a balanced socio-political platform and thereby a healthy
    planet). So my use of the term "message-passing" is not so much
    laden with its use in programming language theory as much as the more
    pedestrian notion of passing notes -- a conceptual model familiar to
    everybody.

    My interest in pursuing the topic isn't to "radically change" Python,
    to grind an axe or personal whim, nor to alter the spirit of Python in
    any way (a spirit which drew me to it back in 2001), but to consider a
    fairly large "re-factoring" or our current *programming ecosystem*
    while preserving and enhancing what I consider Python's main
    superpower: simplifying the complex. The real issue, then, is not
    changing *Python*, but something deeper: refactoring the OOP paradigm
    itself. ...Why?

    First, let it be noted clearly that OOP has not delivered on one its
    two main selling points: re-usable, sharable code. (The other main
    selling point being the ability to abstract away the details of the
    underlying machine -- which it still does well.) The proof of this
    is that we have *libraries* of code bundled with languages so that
    everyone uses the same "vetted" code base. Anything outside this,.
    though, feels, to most, like wearing other people's underwear. You'll
    note, even within the python library itself, that modules are hardly
    unified in coding *style*, showing the programming personality of the
    various developer histories that each library is representing. We
    accept this, because our benevolent dictator accepts it, and it's not
    easy to unify it further (despite an attempt with Pythonv3), because
    the issue, I'm arguing, is really about an inadequacy in the OOP model
    itself.

    What I'm proposing *should* create a data/object ecosystem much like
    Unix created a "command ecosystem". An environment in which people
    could combine simple, modular commands into powerful, complex
    para-applications. In the case I'm proposing, the *Python*
    environment becomes a sort of "lingua franca" for the data ecosystem,
    not because of a war of whose language is better but because of the
    simple issue of practicality. In this data ecosystem, a network of
    objects becomes available and re-usable across the network (not a new
    idea).

    So, where are we now? Well we have this huge resource called the
    Internet, which has loads of data that no one has really exploited to
    its potential. Its value is scattered across the globe: warehoused
    in various databases, spreadsheets, blog silos, personal computers and
    whatnot. The OOP paradigm has not solved the problem, which it, in
    theory, could or SHOULD have. Instead, we have balkanization across
    many language platforms and data formats. XML, RDF, none of these
    really solves the problem, because the relationship to data is still
    too personal to everyone's private taxonomies. Of all the pages out
    there maybe 5% is incorporated into these attempts at data
    standardization. As for Python, its community has sort of splintered.
    Various language attempts to solve certain problems complexified
    the language and created a kind of "growth knot" on Python's tree.
    They weren't bad solutions, they were just the best solutions outside
    a refactoring of the OOP methodology.

    So what is OOP refactored? Building upon Alan Kay's tentative(?)
    description of the OOP "essence" (see
    http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented -- note that
    there are two enumerations of his OOP definitions there), I'm going to
    refactor the view presented there and distill what I argue are the
    main points interest.

    1) Everything is an object. (Purity)

    That's a great idea, and this is where the OOP paradigm has taken us.
    It made a fabulous abstraction away from the machine. But did it get
    us what we wanted? I argue no and apparently others are asking the
    same questions.

    2) Objects communicate by sending and receiving messages

    Great, so why don't we have a standardized way to do this? Currently,
    every programmer invents their own mini "domain language" for their
    objects and modules and it's generally not obvious at all what methods
    are designed to be message passers. ***Why not have a standardized
    syntax for this?

    3) Objects have their own memory, which consists of other objects.

    Ah, but here the object model has not been adequately defined. There
    has to be a "base case" to this infinite regress. What objects do
    integers consist of? I'm suggesting that the OOP paradigm needs to
    define atomic objects, which are not defined by other objects, and
    then start the data taxonomy from there with the first
    object/grouping/container from that. Prototypes, to me, seem quite an
    interesting development here. They make it clear, just like C
    structs, that your building your data upwards, not trying to make
    "castles in the sky". The machine forms a standard basis for
    interaction, over everyone's meta-abstractions.

    4) Every object is an instance of a class (which must be an object)

    Here, I read the world "class" much like prototypes or C structs.
    Here's again, there must be a clear view here to avoid the infinite
    regress. C++ makes this distinction by having types separate from the
    instantiation of same. But that regress must end somewhere, and for
    C++ it's types. One does not ask: "Well, then what is the type of
    type?" There isn't one! The object model in C++ ends there! Types
    are rooted in the machine architecture, but Python and "pure" OOP
    languages are not. And this is where things get hairy and burly.

    5) The class holds the shared behavior for its instances (in the form
    of objects in a program list)

    In other words, the "class" holds the template or the definition of
    each object instantiated (or "created") from it. Hence, I think the
    word prototype is very apropos.

    6) Classes are organized into a singly-rooted tree structure, called
    the inheritance hierarchy. Memory and behavior associated with
    instances of a class are available to any class associated with a
    descendent in this tree structure.

    There is an argument over Kay's meaning here. But the above-worded
    one is the one I'm going to work from. Beginning in v2.2, the "great
    type/class unification" started happening, ultimately leading to
    everything rooted in the Object object. ***BUT*** this is also
    where, I argue, where practicality DID NOT beat purity -- purity
    hammered practicality into oblivion.

    It was a great idea at first, to get completely away from the machine
    -- wouldn't that make inter-operability so much easier? But no, it
    hasn't happened. After the unification things got more complex in
    most ways. And the reason: because the object model must be rooted
    in data, something concrete, not in the abstract which means many
    things to everybody and anything to most others. We're not making
    physical objects or making a simulated environment, so lets not
    pretend anymore.

    What's to replace it?

    1) Objects exists within the concreteness and limitations of the
    machine. (I'm going to limit myself to Turing machines and not deal
    at all with lamba calculii and abstract programming environments that
    exist in the imagination.)

    2) Everything outside the concrete types is an object.

    3) Objects (not the concrete types) talk to other Objects, **otherwise
    they would be a machine type**.

    4) Objects communicate to other objects via a standardized syntax,
    like >> and << for sending and receiving.

    Here endeth the lesson.

    Mark Janssen
    Tacoma, Washington

    P.S. It might be worthwhile to also examine a nice taxonomy of the
    OOP conceptual landscape, found from there, at
    <http://lucacardelli.name/Talks/1997-06%20Everything%20is%20an%20Object%20%28ECOOP%20Prototypes%20Workshop%29.pdf>
    which also partly makes my argument for a refactoring of the paradigm.
    If others find better taxonomies, please forward.
     
    Mark Janssen, Apr 12, 2013
    #1
    1. Advertising

  2. Mark Janssen

    alex23 Guest

    On Apr 12, 11:57 am, Mark Janssen <> wrote:
    > hijacked by naysayers


    Says the man who wrote:

    - "I blame the feminists for being too loyal to atheism and G-d for
    being too loyal to the Jews. Torture happened."
    - "The world is insane because people loved snakes more than G-d, and
    believed in homosexuals more than Adam."

    It's frightening to see that your grip on theology and, hell, *basic
    humanity* is as tenuous as your understanding of computer science.

    Calling out blatant pap as pap is not being a "naysayer". Shouldn't
    you be off single-handedly saving "the creative economy"? What
    happened to your "simple rules to create a self-organized system and
    re-organize the Internet"?

    > Here endeth the lesson.


    I'd love to believe this is true but I bet it isn't; I'm pretty sure
    you've got plenty more delusional grandeur to inflict on us.
     
    alex23, Apr 12, 2013
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Janssen
    Replies:
    0
    Views:
    164
    Mark Janssen
    Mar 20, 2013
  2. Chris Rebert
    Replies:
    0
    Views:
    219
    Chris Rebert
    Mar 20, 2013
  3. Ethan Furman
    Replies:
    0
    Views:
    197
    Ethan Furman
    Apr 12, 2013
  4. Chris Angelico
    Replies:
    0
    Views:
    162
    Chris Angelico
    Apr 12, 2013
  5. Mark Lawrence
    Replies:
    0
    Views:
    125
    Mark Lawrence
    Apr 12, 2013
Loading...

Share This Page