[Edu-sig] FYI: PataPata postmortem link

[Dethe Elza]

On 30-Nov-06, at 3:44 PM, David Boddie wrote:

> On Wed, 29 Nov 2006 10:29:30 -0600, Ian Bicking wrote:
>
> [Constrained objects and persistence]
>
>> In particular cases it might be more reasonable.  For instance,  
>> consider
>> glade (http://glade.gnome.org/) -- it's an XML description of a GUI.
>> For an application that uses Glade and given an editor specific to  
>> that,
>> you could edit the "objects" and then the XML is automatically  
>> written
>> out.  You'd be doing simultaneous editing of the in-process  
>> objects and
>> the "source code", in this case the XML description of the layout.

It's unfortunate that Glade (and Renaissance for Cocoa, and XUL for  
Mozilla, and BML for Java and etc.) are all so closely tied to their  
respective toolkits.  It makes it harder to get good re-use.  And  
having a declarative, HTML-like language for UI building could be  
quite powerful.

[snip]

> Rather than serialising Python objects, it's possibly easier to  
> think about
> describing components that can be implemented in Python. This means  
> that
> you're no longer editing Python, but tweaking parameters for some  
> set of
> components in a flowchart, and optionally rearranging them to do  
> different
> things. Maybe that's a step too far.

This sounds like a Smalltalk image.

>> But really if we can cover a set of compelling things that children
>> would want to edit, an incomplete in-process editing system could be
>> valuable.
>
> I agree.

Oberon, Self, and Hypercard allowed you to get "behind" the widgets  
to see the code they would invoke, and the code that created them.   
HTML and the current desktop-widget tools do this too.  It requires  
some additional work on the UI framework to support this, but a UI  
that was built from Python or XML should be able to support it.

>> Forking would clone a process.
>
> I'm not really interested in cloning the process. I'm thinking about
> restarting individual "smaller" processes - that is, processes with  
> fewer
> responsibilities than normal applications. You would need more than  
> one
> of these to do interesting things, and they would communicate through
> interfaces.

Interestingly enough, Stackless Python can do this now.  You can  
create "tasklets" which are lightweight processes that can be  
serialized, sent over a network, restarted, and communicate with each  
other.

[rest of dicussion snipped.  Interesting, but I don't have anything  
to add]

--Dethe

"Any idea that couldn't stand a few decades of neglect is not worth  
anything." --Gabriel Garcia Marquez