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

[kirby urner]

On 8/10/06, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> 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

Even just basic mathematics.  My idea is to boot programming with the
simplest of sequences e.g. def addone(n):  return n + 1, or thinking
in terms of a while True generator (indefinitely extended sequence).
Conway's & Guy's The Book of Numbers was an inspiration, but I read
Fuller first, coming out of Princeton, so already had the sphere
packing ideas.

> 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

I think HyperCard is a worthy standard to emulate.  Yasushi Kajikawa,
another synergetics pioneer, did some amazingly artistic work in
HyperCard.  His theme was how to assemble 5-fold symmetric shapes,
like the Platonic icosahedron & dodecahedron, with a minimal set of
building blocks or modules.  My friend Koski and I used to obsess
about the same question (actually, he obsessed about the geometry, I
about whether I could understand his results (which I did at the time,
wrote and published about)).

> 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).

I don't expect lone coders to do any more than prototypes.  Finished
products ready for shipping, backed with technical support, are a team
effort.  The question is what's the focus?  Is it to draw attention to
Python's limitations as a professional development environment?  I
think we need to make a sharp distinction between Python the language,
and Python in an environment.  I take it as a given (and perhaps I'm
being presumptuous) that the environment will improve, as Python savvy
matures within commerce and industry.  I've seen debuggers more like
you talk about demoed at OSCON.

Part of why I went into that whole Visual FoxPro (VFP) trip was to
reassure you that I know what cushy environments are like.  When it
comes to drag and drop interface design, simple popup tables with
fill-inable properties, hooks to methods, run time debuggers with
breakpoints, watch tables...  and even I admit, code rewriting on the
fly is a *nice* feature.

I know Python is dirt poor in other words.  But that's a financial
thing, not a language thing.  As a language, it has nothing to
apologize for.  Street urchin with to-die-for kung fu.  What could be
more poetic (or cliche, take your pick).

> 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.

The "aloofness" was with respect to the Pink level, the economy of
PEPs and everyday Python percolation.  It's the workaday coffee world.
 The "respect" (lack of?) was more Blue level, as I think you waste
time insofar as you don't join me in sharply distinguishing Python the
language from issues relating to the level of support Python gets from
industry.

> 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

OK, that's a syntax point.  For the sake of argument, I'll agree with
you:  Python is inferior in this way.  Does that mean it will ever
change?  No, these design decisions have already been made and are
defining of Python as a language.  So is your intent to sort of go "aw
shucks, I wish Python were different"?  For how long?

> 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

As a math teacher looking for an interactive way to teach algebra, I
have no initial interest in any programmer opinions about maintaining
large scale mission critical apps.  These opinions don't drive my
language selection process.  My first question is simply:  where is
the box where the kid types 2 + 2 and gets back 4.  The Scheme people
go "How about (+ 2 2)?" and I say "fine, no problem."  DrScheme is
great, I've never said otherwise.

> 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

I just can't bring myself to care about this issue.  It will never be
relevant in my lifetime.  Python is one way, Smalltalk is another.
That will never change.

> 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.

As a math teacher looking for interactive command line opportunities
for my kids, adult students, I again state for the record that I don't
care about how most programmers spend most of their time.  This is not
about just training up programmers.  Sure, they matter, and sure, some
of my students will grow into such.  But at this initial threshold
level, I'm just looking for "the dot prompt" (xBase for "shell").

> 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).

Right, you're not going to throw your life away trying to make Python
look un-C-like.  That'd be a waste, I agree.

> 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

Not meaning to be cruel or uncaring, but your professional experience
as a programmer of large systems is of no immediate relevance to me,
as a professional curriculum writer working with other gnu math
teachers on such as Pythonic mathematics, which begins, as I said,
with simple sequences.

How will Smalltalk help me with simple sequences, e.g. the triangular
and then tetrahedral numbers?  That's all I want to know.  And the
answer I usually get is:  first, you must go to a special world called
Squeakland.  In Python, I just boot IDLE, enter the function, and run
it.  Oh, so I should have my school go out and buy commercial grade
SmallTalk instead?

> 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

Wins for you.  You, Paul, feel the cushiness of commercial Smalltalk
is way more ready for the back office than dirt poor street urchin
Python, with its forlorn C-like eyes (blink blink).  You want people
to know what your Lincoln Town Car is like.  Heated seats, GPS.

> 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

Curious:  how many hours have you professionally taught other people?
Has that been a part of your job description over the years?  Did you
use Smalltalk in your classes?  How did you introduce the topic on the
very first day (rough thumbnail will do).  These are the kinds of
questions I must answer daily as a writer of Pythonic mathematics, oft
times on a deadline.

> 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

__slots__ was added to help with corner cases where fast access trumps
the ready extensibility of a __dict__ (hashtable lookup).  That might
happen when you need millions of the same type of object, in cellular
automata for example.  Did you see my Game of Life on a Hexapent by
the way, latest addition to my CP4E archive?  Python + VPython.

These figurate number sequences become polyhedral (triangular to
tetrahedral transition).  Big focus of Coxeter's, as well as Bucky's.
Fibonacci Numbers with generators (we're in the 3rd week already?),
with fib.next()/fib.next() taking us towards limit tau, as close as we
like, to within any epsilon (presuming extensible decimal precision --
which we have now (that was a *big* weakness in Python readiness for
the commercial sector, the lack of a fixed precision decimal type,
since added -- have you been following this stuff on contexts?).

> 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.

It's OK to do these side-by-side comparison of Python with Language X
(be that Smalltalk, Ruby, Perl, Scheme, LISP or whatever), but then
there's another question:  what's next?  We could discuss Smalltalk's
and Python's relative strengths and weaknesses until the cows come
home.

But is that Pink Plane or Blue Plane?  I would say neither.

Not Pink, because we're not talking PEPs.

Not Blue, because gnu math isn't about fussing with the low level
syntax of already-specified languages.  We're more zoologists, than
genetic engineers.  We take the species we get, don't seek to create
entirely new ones.  Python is Python.  Smalltalk is Smalltalk.  Ruby
is Ruby.  How much time shall we devote to making that point?

> 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

And go right ahead, but what's the *work* that we're doing?  If the
aim is to teach kung fu to the street urchin, then I think you're just
wasting time.  However, if you want to send a large cheque to the
street urchin, such that it might buy itself fancier IDE clothes, like
the suits have...

> 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.

I think if you seriously respected Python, you wouldn't be sniping at
it from your Lincoln Town Car.

> Anyway, back to more coding.
>
> --Paul Fernhout

Will PataPata help my students do their sequences?  1, 12, 42, 92...
like that.  If you look that up in Sloane's Encyclopedia of Integer
Sequences, you'll find those Fuller School links that I care about.

Kirby