[Edu-sig] PySqueak: more on the cultural divide among paradigms

[Paul D. Fernhout]

Kirby-

Clearly we're both likely on the same planet, but just as clearly our
priorities are different (e.g. I may want to permanently move off of it
more than you :-).
   http://www.kurtz-fernhout.com/oscomak/SSI_Fernhout2001_web.html
   http://www.kurtz-fernhout.com/oscomak/AchievingAStarTrekSociety.html

And there is nothing wrong with that; there is a lot of value in diversity
in a community. One of the marvels of free and open source software
communities is that people work on stuff they like to work on, and others
get to do the same. When those interests overlap, then great. When they
don't, then also great, as the community is still trying a lot of
different things, and the evolutionary results are visible to the
community, and can be built upon as desired. It is frustrating to see all
the duplicated and aborted efforts, but it is also exciting to see an
unexpected effort (like Python once was) catch fire to its fuse and shoot
up to the stars.

Sometimes that work is coding; sometimes it is designing; sometimes it is
just talking about priorities and values and history. Personally, I think
the world has too much code already, and my mission is, in part, to get
rid of much of it. :-) I read once you can measure the power of a new idea
by how many bookshelves worth of books in the library it obsoletes; I
imagine the same applies for code. Again, from:
   http://www.sysprog.net/quotprog.html
   "Fifty years into the First Computing Era some of us in the computing
arena have come to realize we've made a false start, and for us to finally
be able to produce lasting, correct, beautiful, usable, scalable,
enjoyable software that stands the tests of time and moral human endeavor,
we need to start over. (Richard P Gabriel)"
Still, if I can leverage Python and the Python community to that end, then
so much the better. Probably that will fail, but possibly worth the try I
feel.

Anyway, I feel there is room enough for your vision of a "PySqueak" and
also for my vision of "PySqueak". And may the better version win, or
split, or gain adherents, or whatever -- assuming "better" even makes
sense to use when people have so many differing priorities and what is
good for one purpose may be not so good for another. :-)

To recap, as I see it, this PySqueak effort gained some traction when you
and Guido cam back from the summit, having seen Alan Kay's presentation of
Squeak and Croquet. I'm sure it was dazzling, as Alan Kay is a captivating
speaker and Squeak and Croquet have a lot of really great features.(*) So,
with the two of you, who provide a lot of the leadership on edusig,
suitably impressed with the potential for dynamic interactive environments
based on a prototype paradigm for use in education (as well as general
programming), some discussion starts here. And I butt in, and say, hey,
that's what I was talking about six years ago. :-) And so some further
discussion ensues (complete with educational paradigm distractions :-).

Now by all means, I think a popular and well supported open source
Croquet-like 3D environment on Python would be a good thing. I believe
that for the same reasons I think it was neat in LearningWorks, the
original Python Alice (which I played with many years ago):
http://www.cs.cmu.edu/~stage3/publications/95/journals/IEEEcomputer/CGandA/paper.html
VPython, and other systems as well. And even in ActiveWorlds, which bills
themselves as: "Home of the 3D Chat, Virtual Reality Building Platform".
   http://www.activeworlds.com/
and see "Python for ActiveWorlds"!
   http://www.crepuscule.com/aw/
But I could also add in many MUDs and MOOs and MMORPGs of various types
(textual and graphical of various sorts, including even franchised ones).
These things are all really neat. And I can see how the could be
motivating to some people to do some interesting learning. I'd love to
have a good one to work with in Python to simulate life in a space habitat
network, for example.

And if Shuttleworth wants to help fund such a thing,
I'm not above taking some of his money as a subsidy :-) if it otherwise
links in with also advancing some of my own constructivist agenda items
(though they clash somewhat with his school-based approach). Clearly, and
I think correctly for his plans as he sees them now, his strategy,
reflecting your emphasis that Python-as-it-is can do a lot of neat
educational things, is a very good one. I might quibble with the school
orientation, and while wishing him success expect him to need to revise
those plans someday for reasons previously outlined, but it is his money.
Certainly I come with my own set of baggage (re unschooling and free
schooling) so I can acknowledge there are probably many better or more
compatible candidates than I, just on the basis of that, to work closely
with a Shuttleworth activity targeted at schools (and, of course, there
are much better Python programmers out there than I too).  And no bad
feelings should someone else get paid to do that work. Good for him/her.
Frankly, Mark would probably be better off spending his funds on any new
development in South Africa anyway (where his money is based), where he
could hire more developers for the cost of less US ones, plus these
developers would become greater assets to the SA economy (though he made
it clear in the email Guido forwarded that he had little interest in
spearheading a major development effort of any sort, anyway).

So, I think we can discount the Shuttleworth Foundation as the major
player in PySqueak. Not inconsequential, and not unimportant, and of
course not uninstrumental (such as by bringing Guido and you and Alan
together), but just not dominant (at least, right now). As you say, they
are happy with what they have right now, and see the major need just
making curriculum guides using existing tools. Good luck to them with
that, and I hope it works out well despite my reservations, etc.
And I'm sure that may be their (initial) attitude towards a PySqueak.

But, even if that foundation fully underwrote the full-time cost of a
developer or project manager working on a semi-volunteer pay-scale (which
does not even seem to be what they proposed) the effort will only succeed
with buy-in from members of the Python community (and possibly members of
the Squeak community). So the question then becomes, what makes sense to
various people in the community willing to volunteer time to do some
coding, contribute ideas, write documentation, draw icons, submit bug
reports, testing, provide advice, and so on towards PySqueak?  Who are
these people? Well, right now, you are still stuck with just me. :-)
     http://sourceforge.net/projects/patapata [no code there yet]
And hopefully someday, some others. And, we all might never agree, but
maybe some useful things will hopefully come out of that anyway. :-)

Or, more seriously, given that those other 3D Python technologies exist
and have not set the world on fire, and Jython exists and has not set the
educational applet world on fire, and ActiveWorlds and LearningWorks and
so on exist and have not set the world on fire (in such a way you
personally are willing to dump Python just to have 3D worlds), and given
that Squeak and Croquet exist and you would rather reinvent them in Python
than retool in Squeak Smalltalk (a few weeks for you, I'd say, tops, doing
a medium sized app, to be feeling comfortable), given all that, I question
that another stab at 3D worlds on Python will set the educational world on
fire (especially as you can apparently even script ActiveWorlds with
Python already, though obviously that is not the same as Croquet). All
that is very neat, yes. Fun to do, yes. Worth taking money for to put food
on the table and honorably do what you said you'd do, yes. Useful as a
vehicle to build other things on top of and a way to learn such a thing by
working on it, yes. But, is reinventing
Squeak-and-Croquet-as-it-is-in-Python something to knock yourself out for
if you think some other more basic issues are more important, then, no.

And I fall into the "no" camp in that sense. Porting Squeak and
Croquet (or a 3D engine) to Python, when I could just use Squeak and
Croquet and OpenGL, seems like not the most fun or productive thing I
personally could do with years of my time (others might like it more, and
find more value in it for them, of course). But, approaching it as I
outlined, trying to take the best of the *ideas* from Squeak and Croquet
and Self and constructivism and trying to bring them to a Python platform
in a Pythonic and hopefully better way (and with special emphasis on
unschooling and informal science education), or in essence, to "burn the
disk packs" and try to out-Squeak Squeak, now that begins to sound worth
trying (for me). And if approached respectfully, I think Alan Kay's group
as well as the Self group could be some part of that. I'm sure by now
after about a decade of Squeaking that Alan's group knows (at least
intuitively) more about the limitations and disappointments and
frustrations of what they were trying to do with Squeak and Croquet than
anyone (whether they will list these and admit them, given a need for
hype for funding, is a different story). Something I myself wrote on that
topic in 2000 to the Squeak list:
   "Belling the cat of complexity"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html

And, IMHO, for me, it is still worth trying to make a better-than-Squeak
constructivist system with Python even if it is harder and more likely to
fail than porting Squeak-as-is to Python, because it is IMHO
more likely to succeed in the world if it really works out, more than a
"me too" Squeak clone in Python, which without a community that likes it
and uses it, will just wither. And Squeak already has the community
(though Art has some strong words written to this list on the compromises
involved to get there, which are starting to reshape my views on this).
Getting a community is much harder (for me or any programmer) than writing
code. Which actually is an argument for me to, say, jump ship to, say,
Self or Squeak as it is, but let's ignore that, based in part on the fact
that for me, I see Python skills a having a significant potential current
and future commercial value, as Python is up and coming, whereas
Smalltalk, sadly, is on the ropes :-( (Ah, but the good old days with
Smalltalk were very good indeed :-).  Still, part of my writing here is to
think in public about whether any aspect of this project makes sense for
me (as opposed to, say, just switching to Self). I might still decide it
does not make sense for various reasons, not the least of which might be
if the edusig community and its culture really don't want something like
Self built on Python. [I am at least heartened by a few people's comments
here, Ian's especially.]

Of the development plan I outlined for a PySqueak approach, the last part,
the focus on 3D worlds, was of much less interest to me than the other
parts. To me, what makes Smalltalk great is the ability to debug and
inspect and reprogram anything you see, and the beauty of Squeak, in part
as a reflection of "Self", is in the power of constructivist ideas
relating to the GUI, although going beyond that. I don't want to ignore
the other neat technological ideas in Squeak ranging from direct pointer
object IDs to the underlying network OS ideas, but they come second in my
opinion to what makes Squeak attractive. Without the programmable
interactivity, you are left with a scriptable ActiveWorlds, which we have
now!. And also, for me, especially having read things here on edusig
about the value of interactivity on
the command line, about the value of learning different ways of doing
things, and knowing about how "what you see is what you get" can be
superseded by "what you see is really neat and useful", and even some
off-list discussions with Art (Guido's comment comparing us prodded me to
look him up :-), these all make me realize that while there is value in
providing people a concrete 3D interface, I also think there is greater
value in giving people a range of tools and representations, perhaps
implemented by a different variety of systems. And, the 3D worlds can
actually take away from a focus on the basics of programming.
To fight that all by pushing  "one 3D VM to bind them all" :-) in a
"Snow Crash" sort of way
   http://en.wikipedia.org/wiki/Snow_Crash
is just not going to work (at least anytime soon), and is definitely not 
the Python (glue) way. To paraphrase, the great thing about standard VMs 
is that there are so many versions of them to chose from.

On a practical basis I agree with you that expecting to make progress
changing the Python syntax in any significant way is unlikely to go
anywhere. But I also think it is feasible to consider minor changes to
Python to support better introspection or object building, although,
frankly, I think a lot could be done with Python just as it is right now.
Specifically, as I and others stated, one can extend the libraries, or
write new libraries, or create a prototype base class, or use Python in
new and unexpected ways (like writing image files as Python source), or
one can push for new networking paradigms and standards (like Python apps
having a low-level networked programming interface if started with a
debugging thread). So, there is a lot of mileage one can get from those
directions without touching syntax, and I think they remain to be explored
in depth. But, without discussions on these points (even if sometimes just
soliloquies), I don't think some of those ideas would emerge. And they
would not have a chance to be archived for future reflection or Google
searches, or commented on as stupid or redundant or insightful or whatever.

I come to Python from Squeak and other Smalltalks (though I first learned
OO with ZetaLisp on a Symbolics). And I find much to be missed from those
days in Smalltalk, ranging from not needing superfluous periods between
accessors [e.g.  "f v append(poly verts[i])" instead of
"f.v.append(poly.verts[i])" if Python dropped them] to simply always
having a debugger I can code in at hand when an exception pops up
anywhere. Python, its Occam-style indentational syntax (I learned Occam
first), and above all its community, are so fantastic in so many ways that
they make up for much of what is missing on a practical basis. But there
still remain missing pieces. And when you see a presentation by someone
like Alan Kay, he makes you very aware of them, either consciously or
unconsciously. Still, Squeak misses things Python has too (like the "open
source" license, and the stability, and the libraries, and the glue-like
philosophy). So, I am coming from that perspective of getting those
missing Smalltalk basics working first for Python (and ignoring historical
syntax "bugs" like the superfluous period from C/Pascal syntax
compatibility). Only then, using hopefully better tools for managing
complexity, would I think more about crossing ActiveWorlds with OO
scripting yet again or reinventing OpenGL to get a Python version of
something like Croquet (should either of those really be needed, compared
to working with existing Python projects).

Frankly, if you just want Python Alice crossed with a MMORPG, then there
are much easier ways to do it (and probably others potentially more
interested in that, like the people who wrote Python/Alice or VPython or
even one of the Python MUDs or MOOs). But if you want systems that make it
easy for anyone, especially novices, to get involved with programming in
Python (CP4E) then I think taking good ideas from Self and putting them in
a Python context could be a big win, and is something I am interested in.

Anyway, I think the "we" in your comment "we already have sufficient toyz"
doesn't entirely speak for everyone. Clearly, I do not have "Self" in
Python yet, which I want. (Or do I, so much is going on in Python?)

Anyway, same planet, different outlooks. And that makes for an interesting
(if sometimes stressful :-) world.

--Paul Fernhout

(*) The features in Squeak which are impressive are still mostly
derivative in many ways, as I have previously posted on, although many of
the derivations also trace back to Alan Kay and his group in the 1970s, so
assigning such credit is a complex topic.

kirby urner wrote:
> As I understand it, PySqueak is not about changing existing Python
> syntax.  
> [snip]
> The PySqueak effort (badly named?) is more like the VPython effort. 
> Its aim is to give us a sophisticated back end graphics engine to dink
> around with.
> [snip]
> This is NOT about Python changing significantly as a language, moving
> to some new paradigm or yadda yadda.
>
> My info is the Shuttleworth Foundation is in no way holding its breath
> waiting for these newer tools to come over the horizon, exciting
> though these may be.
> 
> In terms of going ahead with implementation, we already have
> sufficient toyz.  Curriculum writing is proceeding apace on that
> basis.