[Edu-sig] OLPC: first thoughts on the first keynote at Pycon

[Paul D. Fernhout]

I doubt this key and related process works anything like Smalltalk, based 
on what you describe, though I have not seen it in action.

In Smalltalk, you can *easily* modify the source of a small part of a 
running program (including most windows callbacks [except for blocks on 
some systems]) and have the changes affect the running program (so no 
restart is required). For small programs this is not that noticeable, but 
if you are developing a large complex application, where it can sometimes 
take minutes to get the program back to the state you are testing for 
(especially if it needs to process large amounts of data), or where 
exceptions may be hard to repeat, this can be a *huge* time saver. So to 
when you are working on a large application which is always running 24X7 
(large financial and simulation and embedded and server projects are often 
like this). This "edit and continue" support is much more fine grained and 
easier to use than reloading Python modules, even with the variants I and 
others have created. Also, if you get an exception in most Smalltalk, you 
can modify the offending code right there and then and restart just the 
method, retaining the entire calling history and values for the call such 
as it was like the exception never happened, without needing to restart 
the entire program (try that in Python. :-)

That is why I feel that Smalltalk programming all other things being equal 
is several times more productive than Python. Of course, all things are 
not always equal, so libraries, other programmer's familiarity with C 
syntax, installed interpreters, relevant libraries, licensing, and so on 
effect the decision. That is why I use Python and typically feel more 
productive *overall* than working in a typical Smalltalk despite knowing 
that when I actually do write and debug my own code that effort by itself 
is much less productive otherwise than doing the equivalent in Smalltalk 
(if all other things were equal, which they are not, especially typically 
in relation to licensing, which may change). Well, I'll say Python's 
indentational syntax is also a big plus which I prefer over Smalltalk's, 
while I otherwise prefer Smalltalk's keyword syntax for being more 
self-documenting. :-).

Anyway, there is no inherent reason Python can not do what Smalltalk does 
-- although it might require some minor changes to the VM to debug and 
restart exceptions; Python just does not do it, I suspect in part because 
key Pythoneers may just not understand what they are missing and think 
module reloading is the same thing. :-) I predict if Guido added this one 
set of related features to Python, it would be a very short time before 
everyone wondered how they lived without it before. :-) However, it would 
also need to interact with the difference between a system hosted in files 
and one hosted in an image, so that part of it would be somewhat harder to 
manage that the internal mechanics.

Thanks in any case for the report!

--Paul Fernhout

Andre Roberge wrote:
> Some excellent reasons were given as to why Python was chosen as *the*
> development language.  There is actually a button on the keyboard
> which is meant to "display the source"; click on it and you're
> presented with the actual Python source code used to run the
> application being viewed/used.  The user can then modify the source
> (like smalltalk I guess, like Paul F. [?] sometimes mentions on this
> list) and run the modified version.