other python ideas

[Douglas Alan]

"Alex Martelli" <aleaxit at yahoo.com> writes:

> I doubt it will be such as an unalloyed blessing as you seem to
> think (what experience, if any, do you have teaching Python, and
> seeing what features give problems and what don't...?), although it
> will surely make the computer-scientist-types happy.

Actually, I *do* have experience teaching Python, and a number of
pupils have been annoyed and rather dismissive of Python because it
didn't have full lexical scoping.  It was also something of a pain to
explain how to work around the problem using argument default values,
and also rather embarrassing because I was trying to convince them
that Python is an *elegant* language.  This work-around is anything
but elegant.

> Scheme, with comparable flexibility (and only a tad more
> complication), has some compilers which generate _splendid_ code --
> yet, alas, it seems to be used mostly in teaching and researching
> CS; nor does CLisp (vastly more complicated, but _rich_ with
> _excellent_ compilers) appear to be anywhere near the road to world
> dom.  So, it's still to be seen whether what you call 'excess
> flexibility' is indeed at all significant as a factor keeping the
> code-generation unoptimized in Python,

I was only paraphrasing Guido when he said that effort would be better
spent on making the interpreter faster, since he didn't think that
there would be all that much of a performance gain by moving to a real
compiler.  I am *quite* aware that the techniques used for compiling
Self could no doubt be used for compiling Python to similar good
effect, but these techniques are anything but straight-forward to
implement and consume a lot of memory, both at compile time and at
runtime.

> AND pretty doubtful that code-generation improvements would be
> significant to Python's success as a language.

It couldn't hurt.  (As long as they didn't come with negative
consequences.)  I know a number of people who would love to use Python
in applications where Python's performance is not considered to be
adequate, myself included.

> Why not give it a try?  There's a project called 'vyper' which aimed
> to "remove excess flexibility" from Python and implement a much
> better code generator for the new dialect/variant -- to top it off,
> from a computer-scientist point of view, the system language for its
> implementation is OCAML (nothing as crude and down to earth as C or
> Java).  I think/suspect it's progressing pretty slowly, as we have
> heard nothing about it for a while -- why not fire up google, find
> all there is to know about vyper, and join the team and/or fork the
> project and move it along on your own path?

In my copious spare time I'll be sure to check it out.  Thank you for
the pointer.

|>oug