[Edu-sig] [edupython] Python in Education Advocacy Article

[Paul D. Fernhout]

To clarify, on PataPata, at the moment I am using Jython to prototype a
version of a Smalltalk-like system and syntax for the Java (JVM)
platform. I am doing this in part to have a system which supports "edit
and continue", and also in part just because it is fun.

I think Java is a terrible language for a human to use because it is too
verbose (among other reasons). Still, after ten years, the JVM is a
not-that-terrible platform which has the advantage of hype and installed
base and can supply about 1/2 C speeds in a portable way. So Java (or
JVM byte codes) isn't that awful as a portable machine language -- and
it involves less work for a single programmer to maintain a complex
application across multiple platforms than for C. Personally, I like
Swing, but then, I come from the world (VisualWorks) where most core
Swing designers come from. :-) There is no question in my mind that
Jython is a much saner way to write code for the JVM than Java in most
situations. And Jython is probably a better choice for most JVM things
than most of these JVM languages:
  http://www.robert-tolksdorf.de/vmlanguages.html
(unless you already know one of the other languages or have a problem
which has a neatly packaged solution in one of those systems).
Still, for anything other than writing arbitrary portable fast code (1/2
C) or code that interfaces easily with Java libraries, Python by itself
is probably a more reliable cross platform solution than JVM approaches
in many situations.

In any case, there is still a lot of Python in my own noodling around,
at least for now. :-) And also, while I learned a lot about prototypes
and their strengths and weaknesses when writing Python code for PataPata
to emulate prototypes in Python, if anything, I developed a better
respect for how much you could do quirky things in plain old Python when
you wanted to or needed to, thus minimizing some of the need to use
prototypes for everything.

Still, there are always tempting new projects like "Factor"
  http://factorcode.org/
which uses FORTH ideals to do amazing things (like with OpenGL) in
fairly small footprints and with minimal external dependencies and with
fairly few core developer-years of work (though the developers are
unusually bright. :-) From the web page: "Factor has an optimizing
native compiler, automatic memory management with a generational garbage
collector, a powerful collections library, and various advanced language
features such as higher-order programming, continuations, and extensible
syntax. Factor development is done in an interactive environment with a
graphical user interface. There is a single-stepping debugger which can
travel backwards in time, and extensive documentation. An easy to use C
library interface allows one to call C libraries without writing any
glue code in C. Bindings for OpenGL, FreeType, X11, Cocoa, and Windows
APIs are provided."  (I can hope AK's FONC
 http://vpri.org/mailman/listinfo/fonc
  http://www.viewpointsresearch.org/html/writings.htm
in a few years will produce something even beyond that, if it succeeds).

In any case, I see the JVM, Python, C, FONC, Squeak, and Factor as all
possible substrates for running a higher level system on top of. A well
designed self-reflective system really should be able to run on all of
them with appropriate back ends and interface layers. It just requires a
higher level of abstraction than, for example, how PataPata already runs
on both top of Python/TK and Jython/Swing. And also a willingness to
sacrifice some performance in some situations. :-)

Right now, on a 3Ghz AMD64, this new VM in Jython is doing about 25000
message sends a second (and about 30K in Python). This is about 1/1000
the speed of C, but I think when the system reflects on itself and can
generate pure Java, I am hoping to have it at Python-ish and Squeak-ish
speeds of about 1/20 to 1/100 C overall for loops and calls and sends.
But given how fast computers continue to get, I'm not too concerned
about performance. Even if it remained at 1/1000 C speed, in ten years,
that would mean it would run about the speed of C on today's computers
-- and there are plenty of interesting applications one can run on
today's computers. I also have Jython GUI that lets me single step
through hand-compiled code. (None of this has been checked in so
SourceForge yet though.) From an educational point of view, looking at
such a system and changing it, even if the system was never used for any
other activity) could help Python-literate people understand more about
message passing and VM construction and (abstractly) how a CPU works.
I'm certainly learning something from it. :-)

I certainly remain completely pro-Python for commercial development.

And I remain pro-Python as the language of choice to teach most kids
with at the appropriate age. It's a great language. And a great
community. Python generally plays nice with other systems (including C
and Java) and looks a lot like what most programmers already know,
making it an easy "upsell" as a dynamic language compared to, say,
Smalltalk or Lisp.
  http://dictionary.reference.com/browse/upsell
And Python has really hit its stride now seeing all the great job
postings for people knowledgeable in it to do very interesting work. If
I was teaching a kid programming right now, I would recommend Python as
the best all-around choice without hesitation, especially as a first
language. (Although, for kids who wanted to be computer or electronic
engineers, I might still suggest Forth as a best first language, so they
learn good factoring habits early on, plus a basic familiarity with low
level issues in an interactive environment. But even then, Python should
come next, for its practicality. :-)

Still, as much as I like Python, I think lack of "edit and continue" in
Python is a big issue -- both for advanced users and beginners,
especially given how Smalltalk, Ruby, C#, Visual Basic, and other
languages have it. Having to rerun Python applications due to typos or
to insert print statements is the biggest thorn in my paw when I use
Python. As I have said, I think lack of "Edit and continue" probably
reduces Python developer productivity to about 1/3 of what it could be
(although you can get part of that back by hacking your application to
use a reloader window like the one I posted on the Jython user list).
Still, even with this glaring handicap relative to other dynamic and
static languages like Ruby or VB or C#, Python still usually comes out
on top IMHO over many other languages for most common programming tasks
for various reasons based on its strengths. Which just shows what an
awesome language Python is, still winning the race while putt-putting on
two cylinders instead of vrooming by on the six cylinders everyone else
has out of the box. Some kinda magic going on there. :-)

I started to look into seeing how "edit and continue" could be addressed
with Python, but, especially given Guido saying it was "impossible", and
looking in the email archives of various lists to see it has been
brought up multiple times on comp.lang.python and such and shot down,
   http://www.google.com/search?hl=en&q=python+%22edit+and+continue%22
it seems it might be easier to build something from scratch which
supports it (on top of Java using those libraries) than to try (and
fail) to improve Python. I also have always preferred Smalltalk keyword
syntax over Python, as it is easily extensible (and easily readable (to
me), so there are always forces tugging me towards creating
alternatives, which people here will rightfully say stand a snowball's
chance of seeing widespread adoption.

The bottom line on "Edit and continue" is that making it work properly
likely requires deep thinking and understanding about the entire Python
runtime system (as well as getting pickup of your changes by various IDE
developers), and Python as a system has moved so far along the
development curve that coming from a standing start up to an
understanding of Python's current internals necessarily beyond that of
Guido (who says it is impossible :-) is likely a long hard effort.
During which time Python will keep moving. It's not exactly a best first
choice of Python internals hacking. Guido is obviously the best person
to tackle it, I think; just need to figure out how to motivate him to
care about it instead of other cool and important things. Now if I could
just get hold of some "first herring" perhaps? :-)
  http://travel.independent.co.uk/europe/article548699.ece
  http://en.wikipedia.org/wiki/Herring

Still, if a student in the "Summer of Code" (or others) got interested
in the project, then I would revisit my personal support for it. I'm
sure it's doable -- just a matter of how much of Python's (or Jython's)
internals would need to be strewn about the floor before it worked (and
an IDE's too, I guess) -- and then how many of those scattered pieces
could be fit back together under the hood. The shortest path is
modifying an existing IDE (PyDev? IDLE?) and an existing Python or
Jython VM so it breaks on any exception before it is thrown (avoiding
the likely most "impossible" part of restarting a thrown Python
exception), and then providing ways in the IDE where you can specify
which modules and exceptions are debugged and which are thrown, and then
having an ability to selectively modify a function and reenter it with
the same preserved entry state (sort of like a continuation). And of
course, you need to then save the change back to the source file. We
already have the reloading code; we would just copy over the one
modified function.

I have poked around some in Jython internals, so for me, adding "edit
and continue" to Jython would be the easier possibility than for CPython
(but of a more limited audience). If I recall correctly, Jython uses
Java exceptions, which are not restartable, so that approach would
likely always be be limited to breaking on where they are raised (unless
the JVM itself changes).

Still, if/when I get the Smalltalk-syntax support on this new base (not
much time for it these days for various reasons), I don't see any reason
a Python-syntax could not also be added to it (especially using one of
the Python-in-Python compilers as the base). So, I fully expect the
outcome of what I am doing could support a Python-ish syntax to get edit
and continue. But that really is not what we all want, as opposed to the
real thing -- Python 2.6 with "edit and continue support". :-) Perhaps
someone with experience writing a PEP might want to work with me on at
least defining the problem in a way it could be formally submitted?

Of course now that I look even harder at people's comments on "edit and
continue" I just came across this:
  http://haacked.com/archive/2006/02/08/OnReligiousWarsinSoftware.aspx
listing "Edit and continue" as #5 on "Well Known Religious" wars. :-)
Which completely surprises me how people could be against it (and yes, I
have read some counter arguments,
  http://www.codinghorror.com/blog/archives/000507.html
but never seen one from someone who had ever actually used the feature
extensively, at least when well implemented in a system like Smalltalk,
including ones that allow "coding in the debugger" as a development style:
  http://www.google.com/search?hl=en&q=%22coding+in+the+debugger%22
)

Still, for fixing typos alone, this "edit and continue" feature could
save many people (especially beginners) a lot of time with Python IMHO.
If Python had it, I'd probably stop thinking about Smalltalk so much. :-)

--Paul Fernhout

Michael Tobis wrote:
> This is all great stuff! Thanks to all who responded here or in email!
> 
> However so far this all goes to only half of the questions I am trying
> to address.
> 
> I'd also like to consider the bad news. At least three important
> projects that I know of have abandoned Python in favor of Java or
> Squeak:
> 
> 1) Alice
> 2) Patapata
> 3) Mark Guzdial's CS for artists course/textbook
> 
> It is also plain to see that self-directed web-centric beginners are
> more likely to gravitate to Javascript, Actionscript/Flash or PHP.
> 
> What are the roots of these choices? Should we be concerned about
> them? If so, is there anything we can and should realistically do
> about them?