Why Python?

[Hung Jung Lu]

Gerhard Häring <gh at ghaering.de> wrote in message news:<mailman.21.1078156622.22701.python-list at python.org>...
> 
> One debugging feature that Python doesn't support is "edit-while-debugging" (edit 
> the function/method) you just debug, something which is possible in VB and VC6, 
> for example) I think it'd not be *that* hard implementing it. Maybe a Python IDE 
> vendor will implement it some day.
> 
> -- Gerhard

I have used Python's reload and weakref to build classes and have
succeeded in develop simple UI programs in a non-stop fasion, i.e.,
you build your application while it is running, without needing to
shut it down and restart (theoretically.) It's like open-heart
surgery.

I believe VB and VC6's "edit-and-continue" does not roll back states
(neither does my Python program), which kind of makes them less
useful. I mean, you cannot use this feature to build up an application
truly in a continous, non-stop fashion. If for some reason you have
modified some states, you will have to restore them manually, before
you continue with the new debugged code.

A true "edit-and-continue" is somewhat related to two areas of
computing that I am aware of: (a) reversable computing, (b)
prototype-based programming languages. The first one is highly
theoretical, and claims that if everything is done right, our
computers will dissipate zero heat due to the conservation of entropy.
Reversing execution effects in these software/hardware combos is
always possible. The second one allows the programmer to easily build
surrogate objects, and commit the changes only at the end. (This will
dissipate heat with current hardware/software configurations.)
Moreover, surrogates can be built as onion skins, so even if you
commit the changes at the outter layers, you can still roll-back at
the inner layer later. Prototype-based languages thus may enjoy a
territory that common class-based OOP language do not. Theoretically
it's possible to build an application in a non-stop fashion this way,
but of course there are constraints from memory size and
non-compliance from existing libraries written in traditional
languages that do not support roll-back.

regards,

Hung Jung