Python is readable

[Nathan Rice]

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.