Python for Kids

[Glyph Lefkowitz]

Sorry for the long delay on this response!  I accidentally hit 'save
to draft' when I meant 'send', and just found it lying around in my
drafts folder...

"Jeff Massung" <jmassung at magpiesystems.com> writes:

> Interesting. I first learned Basic, Pascal, C/C++, then Hypercard (it was
> all we had at our school). So it is good to see the perspective from the
> orther side.

Well, happy to be of service :-)

> >It's also a very bad way of thinking about programming -- the
> >HyperTalk reference lists hundreds of "commands" that are bindings to
> >specific functionality, rather than methods or functions; there's no
> >good way to define a new kind of class, let alone inherit from an
> >existing one; there are scads of subtly special syntaxes, the language
> >is hard-wired into a vastly substandard development environment, and
> >Apple has no intention AFAICT of supporting this under OSX.
> >Abstraction?  Hah!
> 
> Definitely no disagreement here, I just thought that with the GUI idea of
> Hypercard would help the learning process. It is interesting to learn the
> exact opposite! I wonder why...? :)

The GUI in hypercard is completely different than the GUI everywhere
else.  Take the (I believe valid, tho it's been a few years)
statement:

        put 5 into card field "bob" of card 2 of background 3 of window joe

or this one:

        lock screen
        get the value of card field 6
        put it into x
        set the label of button "bob" to x
        unlock screen

Any sane, reasonable programmer would then assume you could do things such as

        put card field 6 into cf
        get the value of cf

except the first statement is invalid.  "card field 6" is not an
object, it's just an expression which has a certain meaning in some
contexts, and not in others The python way of doing these things looks
less like english:

        window('joe').background(3).card(2).field('bob').value=5

or

        screen.lock()
        x=self.card.field(6).get_value()
        self.card.button('bob').set_title(x)
        screen.unlock()

... but then, if you want a programming language that looks like
english, use COBOL.  At least it does math right. ;)

> >No offense to the poster of this message, but HyperCard was what
> >taught me never to rely on commercial software :-) and I really feel
> >strongly about discouraging its use (no matter what the context)
> 
> None taken ;), but I'd like to know why, is there psych. behind it? Failure
> to see what is "really going on behind the curtains" that inhibits the child
> later?

There's some psychology behind it ("scripting is something users do
and programming is something developers do" was one of the most
damaging assumptions about programming I ever internalized -- I was
*determined* to stay a "user" because "scripting is easy and
programming is hard" - I'm not the only one who felt this way,
either); but there are some very practical concerns as well.

Take, for example, the standard way of building data-structures in
hypercard.  The only data-type available is the scalar: which is
assumed to be a string.  Numbers are only a performance hack, since if
you wanted addition, you'd just add two scalars (termed "variables" by
the reference, I think): "3"+"5" = 8.  (3 && 5, btw, is "35").

Since there is no concept of a "list" (except perhaps "list of words",
as in the statement 'put word 5 of "this is a list of some words" into
card field 5') the way you build complex data-types is by (1) creating
a graphical component in the development environment, (2) making sure
that said component has some way of being created from a script, and
(3) putting text fields onto that component.  So every time you want a
struct which is basically 2 booleans, a string and an int, you end up
creating an entire GUI layout which is then (wait, this is the best
part) saved to disk! (but even cooler, in the earlier versions, was
this DIDN'T mean you get persistence for free (not that this
persistence model scales beyond 100k of data)... the data will only be
saved if you explicitly request it, but the layouts will be saved
automatically.  go fig.)

And once you've gone through that whole mess, you've got a data
structure which is about as easy to access as string manipulation in
INTERCAL.  Observe: here is a (again, I don't remember the syntax
completely... I think I'm screwing some stuff up) function to retrieve
a person's age from their name:

function getAgeOfPerson PersonName
   get the value of bg fld 3 of cd PersonName of bg 1 of wd 3
   return it
end function

And to create a person:

function newPerson PersonName
    new cd PersonName of bg 1 of wd 3
end function

And there you have it.  Only 4 lines of code and about 30 words to
incompletely and special-case describe the python '.' operator in a
purportedly high-level language that should have it already, and with
80x the overhead, at that.  And tie-ins to the GUI that are hardcoded
in the most arbitrary and bizarre ways. I could go on, but I think you
probably get the point by now.

programming-should-be-taught-with-nothing-but-a-text-editor'ly y'rs,

-- 
                  __________________________________________
                 |    ______      __   __  _____  _     _   |
                 |   |  ____ |      \_/   |_____] |_____|   |
                 |   |_____| |_____  |    |       |     |   |
                 |   @ t w i s t e d m a t r i x  . c o m   |
                 |   http://www.twistedmatrix.com/~glyph/   |
                 `__________________________________________'