How hard would it be to give it to him? Laura ------- Forwarded Message Return-Path: edu-sig-bounces@python.org Delivery-Date: Sat Mar 31 06:18:19 2007 From: "Paul D. Fernhout" <pdfernhout@kurtz-fernhout.com> User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: "edu-sig@python.org" <edu-sig@python.org> 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?
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig ------- End of Forwarded Message