[plt-scheme] An Editors Tale

Ken Anderson <kanderson at bbn.com> writes:

> Do you really mean "most"?

Matthias has answered some of this, but I thought I'd throw in my $.02
as well.  A couple of months back I was arguing with a Pythonista
about the pros and cons of Python and he challenged me to attack a
`real world' problem and compare it to his Python solution.

Python has an execution model where the environment is represented by
a hash table (they call this a `dictionary').  It is not uncommon to
manipulate this structure directly to introduce new bindings in a
rather undisciplined way.  The Python class structure is built upon
this model.

In any class-based object system, there is functionality that is
provided by the class system (hierarchy, inheritance, specialization,
encapsulation) upon which the user implements the behavior of whatever
it is he is modeling.  The Python class system works by creating
dictionaries with `hidden' fields and methods that implement the class
functionalities.  So, for example, all classes have a hidden method
that is called when the interpreter attempts to assign a value to a
class field.

The problem is that these fields are not particularly well hidden.  It
is quite common to modify the meta-level functionality on a class by
class basis by overriding the __init__, __getattr__, __setattr__,
__getitem__, and __setitem__ fields.

There really isn't a well-defined reflective meta-level to the class
system.  Pythonistas change the meta-behavior by ad-hoc reprogramming
of the interpreter.

> If by "translucent" you mean that a class can take on new fields and
> behaviors, i think that can be important for piecemeal growth of an
> application.

Agreed, and the meta-level should provide a mechanism for doing such a
thing.  The meta-level procedure can have a documented behavior that
can be reasoned about.  But Python does not have this.  The fields in
an object are determined dynamically by the object itself, and the
user may have overridden that method.

Advanced object-oriented concepts, like mixins, are implemented by
creating a class that when instantiated within an object, calls `eval'
to redefine certain methods within the object.

> Isn't there a point when a python application, or library can be
> treated as object oriented and then reasoned about?  

Unfortunately, no.  There is no `declarative' class structure.

> Or is it like TCL where eveything is a string and unimaginable
> string hacking can take place anywhere? 

Pretty much, except that it is all hash tables.

It reminds me of Lisp in its extreme youth where the value and
function cells were kept on the symbol property list and people felt
free to manipulate them in undisciplined ways.  Its very flexible and
powerful, but the lack of discipline makes it impossible to reason
about.  Since those days we've learned that we can achieve the same
results in a structured manner.  Python is still young.