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. -- http://mail.python.org/mailman/listinfo/python-list
