MOAR TROLLING... >> In my opinion, people who make statements such as "#1/2 are imperative, >> #3 is OO" are missing pretty much the entire point of what OO is. >> >> OO is much more about semantics and the way code is structured. The >> difference between #1/2 (especially #1, of course) and #3 is >> surface-level syntax only.
The idea of actions as concrete attributes of entities is probably the worst bit of object oriented programming, except perhaps inheritance. Events occur in the context of multiple entities, but they are conceptually distinct and should not be subordinated. Furthermore, if you have an explicit self or this context, your ability to override elements of an event is limited to things which are directly encapsulated in that context. Additionally, dynamic dispatch induces overhead and the possibility of action at a distance. Reflective template meta-programming and explicit attribute delegation are VASTLY superior. To rant about inheritance, outside of mathematics platonic ideals are bullshit. Natural kinds are the closest we might actually be able to come to ideals, and philosophers still debate whether atomic elements and subatomic particles should have this designation. On the macro scale, classes or types are dynamic, fuzzy unions of structure, context and intent. Making any sort of invariant categorical statement about real things is just begging to be proven wrong. Programmers would be much better off if we made assertions about relationships and structure with an explicit, contextual reference. I think this would simplify code reuse, since you would be able to compare contexts to know if program elements were compatible and programs could be assembled by the union or intersection of sets of assertions. >> About the strongest statement you can make along those lines is that #3 >> will allow you to do dynamic dispatch on the type of 'stack' while #1/2 >> won't, but even that isn't true of course. For instance, CLOS will let >> you write '(push stack item)' (which is the direct analogy in that >> language to #1) and do even more powerful dynamic dispatch than what a >> language like C++, Java, or Python will let you do. >> > > In the grand scheme of things, of course code structure and semantics > are more important the surface-level syntax. > > If you take it as a given that structure/semantics are sound (big > assumption, I know), then the next issue with regards to "readability" > is the syntax itself. Sadly, defining sound (i.e. valid) language semantics is not terribly difficult; Turing complete systems occur spontaneously with surprising frequency in nature. The problem is that fundamentally, languages model the conceptual space at large, but language designers choose a semantic vocabulary that models their minuscule subset of that space. This semantic vocabulary is by its nature static, while the conceptual space is dynamic. We aren't going to get semantics really right until we model the dynamical meta structure of the concept space, and put abstract structure, context and intent at the fore. As for syntax, we have a lot of "real" domain specific languages, such as English, math and logic. They are vetted, understood and useful outside the context of programming. We should approach the discussion of language syntax from the perspective of trying to define a unified syntactical structure for real these DSLs. Ideally it would allow representation of things in a familiar way where possible, while providing an elegant mechanism for descriptions that cut across domains and eliminating redundancy/ambiguity. This is clearly possible, though a truly successful attempt would probably be a work of art for the ages. -- http://mail.python.org/mailman/listinfo/python-list
