Re: [PataPata-discuss] [Edu-sig] Freedom: some Smalltalk history and Python implications

[Paul D. F. <pdf...@ku...>]

Kirby-

Thanks for the insightful comments, including about "vacation" languages, 
which I agree with.

You make a good point distinguishing conventional content (astronomy, 
higher mathematics) from programming issues. I guess my answer there is 
handwaving about the potential for a PataPata version of HyperCard as an 
authoring environment. Now that is still just mostly vaporware at this 
point, though closer to substance than it might look in some ways, i.e. 
you can already plop down buttons which do things or open other windows, 
but it is vaporish in the sense of not being done with the elegance of 
HyperCard. So, in that sense PataPata falls in the category of trying to 
make a Python GUI easier to build than existing methods. Perhaps it fails 
at that still (no documentation, probably bugs, perhaps performance 
issues, and so on), but anyway that's part of that hope. Of course, I 
could do even more handwaving about things that are just twinkles on the 
horizon about large projects being easier to maintain and debug using 
prototypes like Self and integrated development tools similar to 
Smalltalk, but clearly PataPata isn't showing that yet (i.e. prototypes 
add another layer of clutter right now including strange error messages, 
and there is no integrated debugger).

Still, I don't think your characterization about "respect" or "aloofness" 
are accurate, and (as in the past with such comments I usually let slide) 
are perhaps verging on twising thigns in an ad hominen fashion. One can 
"respect" a language while still being critical of aspects of it.

In the syntax case, I am continuing to point out that Smalltalk's keyword 
syntax (e.g. "Point x: 10 y: 20" versus "Point(10, 20)" ) produces code 
where all arguments are labeled and so it is easier to read and 
understand. As I see it, that is a fact independent of licensing, object 
models, breadth of libraries, size or quality of community, or engineering 
reliability of the VM, and so on (areas which Python often has as an 
advantage over any specific Smalltalk). From a programmer point of view, 
thinking about maintaining a large system, that one syntactical point is a 
big win for Smalltalk and the Smalltalk culture. And, while I can label 
arguments in calling Python, as in:
 >>> class Point:
...   def __init__(self, x, y):
...     pass
...
 >>> Point(x=10, y=20)
that call is syntactically noisier (i.e. more special characters) than the 
Smalltalk-ish:
   Point x: 10 y: 20.
and clearly not how the bulk of Python code is written.

And in Python, the internal names of variables are then exposed into the 
API and then effectively fixed in concrete and immune to easy refactoring 
(without introducing another layer of variables in the function). Also, 
for beginners, Smalltalk code is then easier to understand (assuming the 
beginner isn't already steeped in a BASIC or C or Java or Scheme 
background). And programmers spend most of their time reading code, not 
writing it.

When I refer to "politics" I don't mean mainly in the PEP sense -- but 
more in the issue of seriously (not this level of chatter) lobbying for a 
language feature to people who are embedded in a C mindset against a 
community norm, where there is unlikely to be change and is likely to be 
outright misunderstanding and hostility (as Prothon etc. show). And where 
the language (Python) succeeds in large part exactly because of its syntax 
looking familiar to the majority of existign programmers (i.e. like C).

And I am still unable to bring across the massive decrease in 
effectiveness and immersion I feel programming a large system in Python 
compared to Smalltalk, like were when an exception is raise I cannot 
immediately change the code and then carry on from the point in the 
program where the exception was generated, without either restarting the 
entire application. Granted, with some user added code (including from 
more general approaches I've posted to the Jython list) one can get a 
specific Python application to the point where you can reload some 
libraries and continue after an exception with modified code but usually 
only from the top of the event loop (so, redoing a menu selection or 
button press for example). I have used that in making one medium sized 
application in Jython. But that level of support is both dependent on 
active user modification of their program to have such hooks and limited 
in how well it works and certainly is not in the same level of what almost 
all Smalltalk support. And it is not the community norm. So, if you have a 
big application to develop, Smalltalk wins on this front as well. But also 
from a learner point of view, I think Smalltalk also wins here -- and 
beginner's programs often have many errors, and a restartable debugger can 
help them understand what is going on, keeping them in the flow of their 
program more than starting their application over every time an error 
shows up, or worse, trying to put in by hand all sorts of specific code 
for module reloading which often does not work as expected.

Now, I have repeatedly agreed Python has many benefits over Smalltalk. 
You've mentioned some. I'll add, Python is more "prototypish" than 
Smalltalk because it uses a dictionary instead of fixed slots for 
variables (at least, usually) which make it easy to specialize instances 
of a class. Python as a major language had a free license unlike the major 
Smalltalk dialects (i.e. there are free Smalltalks but they are still 
marginal to the overall Smalltalk community, Squeak being the closest to 
an exception). Python has had its internal complexity managed fairly well, 
compared to say, Squeak because of having namespace from the start. I like 
indentational syntax (though not as much as keywords). Metaclass support 
is nice. And so on.

So I'm not "disrespecting" Python that I can see, though I am being 
critical of specific areas where Smalltalk has long been superior. I am 
saying Smalltalk as a phenomenon has these two major benefits over Python 
-- common use of keywords and common use of a restartable debugger -- and 
then also saying Self or NewtonScript as a phenomenon shows the value of 
prototype oriented programming. And then I have spent person-months trying 
to do stuff to add to Python in these directions in various ways, so, both 
talk and action. So, that is why I don't see the "spin" you are putting on 
this as "disrespect" or "aloofness" is accurate.

Anyway, back to more coding.

--Paul Fernhout

kirby urner wrote:
> Hey Paul, thanks for the lengthy narrative, which I found quite 
> fascinating.
> 
> I want to clarify that when I speak of Smalltalk as a "dead language"
> that's not out of disrespect or dislike.
> 
> It's really OK to be a dead language, and I think what I mean by that
> is it's no longer anyone's ego child, not championed by the living.
> It still may be running mission critical applications however (like a
> container shipping service) and will need to be maintained and/or
> rewritten.
> 
> Sometimes the easiest thing is to just keep knowledge of the language
> alive, like we do Latin, other even more ancient languages (Etruscan
> to some extent).  An elite class of specialist learns enough to
> maintain existing applications.
> 
> But there's no great vision of the future, no expectation that the
> language will be making big leaps.  It's not "alive from the inside"
> the way Python currently is, still taking shape and all that.
> 
> That's not a great tragedy or anything.  Languages are mortal, just as 
> we are.
> 
> Now it sounds from your posts that you still nurture the hope for some
> killer app to rescue SmallTalk (sorry for the CamelCase).  I wouldn't
> say that's impossible.  Computer languages are still relatively new on
> the scene (we're only a couple generations from Rear Admiral Grace
> Hopper), and maybe there's this phenomenon of "language revival" where
> a once-considered-dead language magically resurrects and starts a
> whole new life.  I hear Prague is a big center for FoxPro.  If
> Microsoft kills the Fox, maybe it'll pick up in Prague, some two and a
> half centuries hence.  Dunno.  What if.
> 
> In the case of Python, I don't know yet how deeply you've appreciated
> its intricacies, or are you still skating on the thin ice of "looks a
> lot like C".  The resemblance is somewhat superficial.  Have you at
> least read Martelli's book, Python in a Nutshell?  I'm guessing you
> have, but if you haven't I recommend it.  And go to his talks.  All
> about Design Patterns.  Stuff a Smalltalker might grok.  At that
> level, the OO implementation language is kind of so what.  Python
> expresses the ideas cleanly, but if you have a different shorthand,
> and want to talk Design Patterns in Smalltalk-oriented study groups,
> why not?
> 
> I think we all need a "vacation language" by which I mean a current
> fascination, not so load bearing as to be called "work" let alone
> "mission critical."  For me, that'd be J these days.  It used to be
> Python (which I came to through Java).  Also:  ActionScript.
> 
> When you talk about Prototyping, coming from Self, that sounds a lot
> like how the Flash people talk.  At Saturday Academy, you find a lot
> of young people diving headfirst into Flash.  Flash and Shockwave
> might be two of the biggest hits with a lot of teenagers soon
> (actually, try Gamemaker), provided we succeed in our efforts to
> seriously reschool in some critical path dimensions.
> 
> I think if you don't really respect Python, you won't really be happy
> putting many eggs in this basket.  And I don't see it as my job or
> even mission to "win you over" in any way.  You're a very intelligent
> adult, capable of doing your own brainwashing.
> 
> However, I do cop to seeing you as unproductive/ineffective at the
> Pink level in the Python Community.  If you were serious about syntax
> changes, you'd be writing PEPs, but you've already declared your
> aloofness from politics (PEPs get political -- you have to defend them
> on comp.lang.python and places).
> 
> At the Blue level, I think you could beneficially focus on
> language-independent content, so long as you want to hang in the
> Python community without really having an in-depth appreciation for
> Python.
> 
> What were kids supposed to DO with PataPata.  What's the curriculum?
> How do star systems and navigation fit in?  When do we start talking
> about topology?  How does the calculus figure in?  Kay talks quite a
> bit about teaching calculus.
> 
> These are the kinds of questions I face daily when writing a Pythonic
> mathematics curriculum.
> 
> It's not that much about syntax -- although I must say I was pleased
> with that  fib.next()/fib.next() convergence, using generators, to
> 1/phi or tau or whatever (.618...).  I think the idea of generators,
> coding them, will help with the idea of limits, as the post-Newtonian
> French conceived them (L'Hopital et al).
> 
> Kirby
> 
>