[Edu-sig] PySqueak: More on Croquet and 3D

[Paul D. Fernhout]

kirby urner wrote:
> That will never happen, except sure, maybe *some* people will eat
> their own dog food in this regard.  In general though, people are too
> curious to ever alight on one generic omniembracing containment
> system.  That's what reality is for.  Within reality, all GUIs are
> special case.

Good point. Funny thing is, as I think about it, that Croquet to some 
extent perhaps repeats the thought of the original Macintosh Desktop -- 
that is, give people a desktop they are comfortable with and they can 
easily use it. The problem is, that things didn't always do what people 
expected, and the desktop metaphor can be pretty limiting.

By the way, as I though about your use of "first person" (I) and "third 
person" (he/she/it) for interface types (exemplified by 3D shooter vs. 2d 
map with markers) I realized that for completeness one should consider 
"second person" (you) interfaces, which I would think would be more like 
conversations, e.g. ("Computer, you should really print out my reports, 
please." :-). [I have worked somewhat in the past on such speech driven 
second person interfaces.] Likely there might be other versions related to 
tense or indirect reporting of things. Some more ideas here:
   http://en.wikipedia.org/wiki/Grammatical_person
 From there: "The grammar of some languages divide the semantic space into 
more than three persons. The extra categories may be termed fourth person, 
fifth person, etc. Such terms are not absolute but can refer depending on 
context to any of several phenomena."

> That being said, let's use Croquet sometimes, why the hell not?  I'd
> especially like it on a much bigger screen with a projector, and with
> less of an Alice in Wonderland flavor (I've already got Alice, the
> computer game, which twists the scenario into something darker and
> more gothic -- closer to Batman in flavor, and therefore more
> comfortingly all-American in my book (but who wants something that
> twisted for an interface? (we should at least be able to "skin"
> Croquet in some dimensions, according to personal taste, if it really
> purports to be more of an operating system and less of an
> application))).

Interesting idea...

> Some will experiment with other shapes of screen.  Imagine the
> challenge of fitting a GUI to an hexagonal frame.  Very Klingon.  Very
> Dymaxion.

Definitely the promise of making systems you can "glue" together.

By the way, no hexagons yet, but this project
   http://sourceforge.net/projects/patapata
is up to "proof_of_concept_021.py"
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_021.py?view=markup
which finally has gotten to the point where I can edit what morphs do in a 
very limited sense. You have to put your code in like this:
   PrototypeMethod(self, "def grow(self): print 'grow changed'\n")
and you can only modify existing methods.

These proof of concepts have brought home hard one major language 
impedance mismatch issues trying to use Python to be like "Self" or 
"Smalltalk": Python is oriented around supply a function and then calling 
it, whereas Smalltalk and Self are oriented around message passing. Thus, 
implementing "doesNotUnderstand" is possible in Squeak/Self, as is 
executing code on simple accesses (e.g. "self spam"), whereas under Python 
I can't assume what someone retrieving a function or variable plans to do 
with it. That also leads to the issue of dynamically wrapping methods and 
the overhead for it in memory and computation in Python.

Also, I need to think through initialization better, because otherwise 
prototypes which are filling the role of classes have their lists or 
dictionaries shared across all instances, whereas I really want those per 
item. I have a workaround in place but I don't like it. And that gets back 
to a problem with my very first prototype using TK, where I copied a 
prototype which inherited from a TK widget, but the widget itself was not 
duplicated. I guess I could duplicate that widget as part of a special 
init or copy constructor. If I can manage that trick, then I could have a 
hope of embedding TK or wx widgets into a world of prototypes.

I've continued to look at other languages in terms of how the approach 
some of these issues, and came across this little idea:
   http://www.paulgraham.com/popular.html
""The best writing is rewriting," wrote E. B. White. Every good writer 
knows this, and it's true for software too. The most important part of 
design is redesign. Programming languages, especially, don't get 
redesigned enough. To write good software you must simultaneously keep two 
opposing ideas in your head. You need the young hacker's naive faith in 
his abilities, and at the same time the veteran's skepticism. You have to 
be able to think how hard can it be? with one half of your brain while 
thinking it will never work with the other. The trick is to realize that 
there's no real contradiction here. You want to be optimistic and 
skeptical about two different things. You have to be optimistic about the 
possibility of solving the problem, but skeptical about the value of 
whatever solution you've got so far. People who do good work often think 
that whatever they're working on is no good. Others see what they've done 
and are full of wonder, but the creator is full of worry. This pattern is 
no coincidence: it is the worry that made the work good. If you can keep 
hope and worry balanced, they will drive a project forward the same way 
your two legs drive a bicycle forward. In the first phase of the two-cycle 
innovation engine, you work furiously on some problem, inspired by your 
confidence that you'll be able to solve it. In the second phase, you look 
at what you've done in the cold light of morning, and see all its flaws 
very clearly. But as long as your critical spirit doesn't outweigh your 
hope, you'll be able to look at your admittedly incomplete system, and 
think, how hard can it be to get the rest of the way?, thereby continuing 
the cycle. It's tricky to keep the two forces balanced. In young hackers, 
optimism predominates. They produce something, are convinced it's great, 
and never improve it. In old hackers, skepticism predominates, and they 
won't even dare to take on ambitious projects. "

Anyway, I broke the versions out into separate incremental files so people 
could easily follow what I was doing and perhaps revisit assumptions at 
earlier points. I've reached the point through where for more complex 
prototypes it may be hard to keep them in one file (especially if I 
started testing writing and loading Python files to save widget state) and 
at that point I'd probably start using SVN in a more typical way. (And at 
some poitn I'll probably move all those files into a directory and those 
previous links may break, but the code shoudl still be findable from the 
main project SVN page.)
  http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/

At this point, with a little handwaving about how easy 3D is in Python :-) 
I'm tempted to just do the politician's trick of declaring "victory" (at 
showing Python doing Self-like and Squeak-like and Morph-like things) and 
going home. :-) [Well I'm already at home, so that's just a turn of 
speech, but often good advice anyway. :-)]

Realistically, the last prototype is still quite a ways from where anyone 
would want to use it to do software development (and the inspector is 
still wx and not native), but it does show how (ignoring efficiency) one 
can create a graphical world of prototypes and interact with it 
dynamically using Python. So, it is a tiny fraction of 3D Alice in Python 
of almost ten years ago. :-)
http://www.cs.cmu.edu/~stage3/publications/95/journals/IEEEcomputer/CGandA/paper.html
You can see pessimism is outweighing optimism at this point in my mind. :-)

Anyway, what I can say that is good about it is that *if* people want to 
talk about or demonstrate prototype based languages using Python, this is 
a little example consisting of a single file (~20K) that is a starting 
point for discussion of "prototype vs. class-based" programming,

> PS:  you're mentioned in my blog too by the way:
> http://mybizmo.blogspot.com/2006/05/home-schooling.html

Thanks for the link. IMHO, the reality is that (almost) all learning is 
really learned originated, it is just that it sometimes also happens in 
the classroom. :-)

--Paul Fernhout