[plt-scheme] An Editors Tale

Ah, but the problem is that 3% "black holes" that you inject into a 
program analysis quickly pollute the entire analysis. Do you know of an 
analysis that copes with higher-order objects (closures) and "black 
holes" (without additional information about them)? -- Matthias


On Jan 29, 2004, at 1:11 PM, Ken Anderson wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> Thanks for this detailed reply.  While i've always favored simple 
> flexible languages, you've made their limits clear.
>
>  From my experience with Common Lisp, MOP level programming is 
> typically done only occasionally to provide a specific capability, 
> such as persistence.
>
> To make this quantitative, i looked at Jython 2.1a3, which i have on 
> my machine.
> I found 234 f*.py iles, with 3389 defs.  Here is a histogram of the 
> top 10 def __... methods:
>
>     264  __init__
>      54  __repr__
>      12  __getitem__
>      10  __getattr__
>      10  __del__
>       9  __setitem__
>       9  __len__
>       7  __delitem__
>       5  __str__
>       5  __cmp__
>
> Assuming __init__ and __repr__ are OK to define in normal code it 
> means that about 3% of the methods are at the "meta level".
>
> Looking at some of the __getattr__ methods i see that they do things 
> like "make this object appear to have all the fields of this other 
> object" which is clever, but too clever to automatically reason about. 
>  So i get Matthias' point.
>
> However, if the contamination is only 3%, say 100 methods, maybe some 
> of the libraries can be revised to void this problem.
>
> k
> At 10:03 AM 1/29/2004 -0500, Joe Marshall wrote:
>> 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.