A critic of Guido's blog on Python's lambda

[Ken Tilton]

Lasse Rasinen wrote:
> [I trimmed some of the newsgroups away; this mostly concerns Python and Lisp]
> 
> Ken Tilton <kentilton at gmail.com> writes:
> 
> 
>>Lasse Rasinen wrote:
>>
>>>Ken Tilton <kentilton at gmail.com> writes:
>>>
>>>
>>>>>if any concepts have survived to the Python version. Since Python's object
>>>>>model is sufficiently different, the system is based on rules being
>>>>>defined per-class...
>>>>
>>>>That will be a total disaster for PyCells, if true. But I do not think it
>>>>is. You just need a constructor that takes some slot initializers, and
>>>>initialize the slots to one of: a normal value; an InputCell itself
>>>>initialized with a starting value, if only nil; or a RuledCell itself
>>>>initialized with a lambda.
>>>
>>>Hmm, just tried it:
>>>
>>>[snip example]
>>>
>>>So it does work out-of-the-box ;-)
>>
>>So why exactly did you say that the differences in the object model made
>>it impossible? I was really stunned by that claim. And you sounded so
>>confident. What went wrong there? It was trivial, right? How did you miss
>>that?
> 
> 
> Simple: I didn't think to try that before you asked.
> 
> I did not say the differences in the object model made it impossible, I
> said the system is based on rules defined per-class. 

Oh, please: "Since Python's object model is sufficiently different, the 
system is based on rules being defined per-class".

> I also think(*) that while one would have the option to define
> per-instance rules, in a Python implementation one would structure the
> code so that common rules would be class-related,..

What has Python got to do with it? What you describing is the way every 
OO system other than a prototype-based system works. It is why OO failed 
to deliver on the Grail of object reuse: every time you need different 
behavior, you need a new subclass. Literal values only go so far in 
making instances authorable. But when an instance can have a rule with 
itself as an argument, and when instances exist in a runtime hierarchy 
navigable up and down such that rules have effectively global scope, 
yowza, now you have authorability, amd now you have object reuse.


> and the per-instance
> rules would be used less frequently, used only when you absolutely need
> them.

You will see, but not until you have the capability. Then you will 
discover you absolutely need them all the time. GUIs are dynamic things, 
so you cannot just author a widget with a literal value, it has to be a 
rule sensitive to the state of other GUI elements and the model itself, 
which might be changing underfoot in response to I/O events.

I happened to be discussing this just now over in comp.lang.tcl, 
comparing Cells with Actions, a kindred package motivated by this:

"Two large problems exist for developers of such user interfaces. One is 
the need to constantly synchronize the controls with the ever-changing 
state of the application or data. When no text is selected, for example, 
the cut and copy buttons should be disabled.

"Another problem is that as programs evolve over time it can become 
tedious and error prone to update the parts of the code that act upon 
these controls."

Found here:

http://www.tcl.tk/community/tcl2004/Papers/BryanOakley/oakley.pdf

> 
> (*) Unfounded Gut Feeling(TM); if your project is successful, we can
> revisit this prediction in September ;-) 

No need for gut feelings. Anyone working in GUIs knows the problem 
(stated by Mr Oakley above) and many partial solutions exist, such as 
Tcl/Tk's builtin mechanisms for automatic state management. They called 
the company ActiveState for a reason, you know. :)

One person did his homework. vasilsi margioulas sent me cells-gtk, a 
two-week marriage of cells and Gtk derived from my Cells-Tk effort. He 
was curious if Cells would be useful. he decided, yes. :)


> 
> 
>>>>PyCells looks like it will be a project for SoC2006, so you may as well
>>>>relax.
>>>
>>>You really want to start a SoC project on something that takes about two
>>>weeks ...
>>
>>You sound so confident. :)
> 
> 
> Indeed. Having reread the post I do think the tone was possibly a tad
> arrogant. However:
> 
> 
>>A new test suite, documentation (a first, there is none now), a full port
>>of Cells in all their ten years of sophisticated evolution and variety
>>(no, not your stupid pet trick), and as a demo project an entire
>>cells-driven GUI, probably a port of my new Celtk (+ Cells Tk) work, all
>>in a language without macros, without special variables, with a more
>>modest OO system, and limited first class functions... oh, I think we'll
>>keep him busy. :)
> 
> 
> I did not know all this. The list above does sound like a full summer of
> work ;)
> 
> I assumed that PyCells referred to the core dependency tracking module
> which (even now) does not sound like a such huge task, especially when one
> has the reference implementation ;-)

I think the real problem here is that you have no idea how fast twelve 
weeks can go while programming. The hourly beep on my wristwatch sounds 
like a metronome.

As for Cells being so damn easy, well, yeah, that is how we get sucked 
into these ten year projects. Do you know how long Knuth thought he 
would spend on TeX? Look it up. I have high hopes for you as a 
developer, you are blessed with that essential cluelessness as to how 
hard things will get before you are done.

If you want to insist on how perfect your code is, please go find 
ltktest-cells-inside.lisp in the source you downloaded and read the long 
comment detailing the requirements I have identified for "data 
integrity". Then (a) tell me how your code fails at integrity, (b) fix 
it, and (c) tell me again how easy Cells is. :)

Having the reference implementation is the only thing that makes this 
conceivably doable in a summer. What you are missing is something I have 
often also gotten wrong: the core, cool functionality always comes easy 
in the proof-of-concept stage. We make these ridiculous extrapolations 
from that to a shipped product and come in five times over budget.

Not just the extra drudgery (doc, testing) of a finished product, but 
also what happens when you scale a package to real-world requirments. I 
knew my system was as bad as yours at data integrity for seven years 
before I finally hit an application where it mattered (RoboCup, of all 
things).

> 
> As I said above, I was mostly concerned with exploring how the data flow
> system would work, so I haven't implemented the various different types of
> cells in Cells. So there would obviously be a bit more work if one is
> implementing all that, but still, two caffeine and youth powered student
> weeks can achieve a lot ;-)

See above. That is the fun proof-of-concept bit. And go back further to 
my point about you really not understanding time in the software 
dimension: two weeeks /is/ twelve weeks!

> 
> What "your stupid pet trick" would be referring to?

Just picking off the low-hanging fruit. You ducked all the hard issues. 
I think in another article in this thread I demonstrated how you 
destroyed Moscow.

> The use of the
> __getattribute__ method (which is quite close to SLOT-VALUE-USING-CLASS),
> or the use of @decorator syntax to reduce typing and redundancy?

No, that stuff is fine.

> 
> 
>>Now since you are such a genius, maybe you can help with something. Trust
>>me on this: this is one place where macros would be able to hide a ton of
>>implementation wiring it does no one any good to look at, and actually
>>turns into a maintenance nightmare whenever Cells might get revised.
> 
> 
> I'd probably use decorators a lot, since they let you play around with
> function objects. If they are suitably chosen and designed, the interface
> should stay pretty stable even while the wiring is changed.
> 
> (Decorator background:
> 
> The regular python Python function definition would be
> as follows:
> 
> def foo(x,y,z):
>   ...
> 
> would be in CL (if CL were Lisp-1 with symbol-function-or-value) more or less:
> 
> (setf (symbol-function-or-value 'foo) (lambda (x y z) ...)
> 
> The decorated syntax would be:
> 
> @magic_decorator
> def foo(x,y,z):
>   ...
> 
> and the translation:
> (setf (symbol-function-or-value 'foo)
>  (funcall magic-decorator #'(lambda (x y z)
>   ...)))
> )

Wow. I thought Python did not have macros.

This project is looking better all the time. Thx.

kenny

-- 
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
    Attorney for Mary Winkler, confessed killer of her
    minister husband, when asked if the couple had
    marital problems.