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?

Dethe- Thanks for the links and ideas. I've never tried to work in io, though I had downloaded it and tried to run some applications in it. I can't get past the syntax. :-) I think Smalltalk syntax was one of the things best about it, yet most of the alternatives (like IO) try to put C-ish syntax on Smalltalk ideas. And I do love Python's significant indentation. Anyway, the XO OLPC project and it's "view source key" is a great angle for getting "edit and continue" into the Python mainstream eventually. However, perhaps what the XO OLPC project really needs as well is a "break" key and a "trace" key. :-) Maybe it has them too? Now this is interesting and surprising on Guido's blog post as well: http://www.artima.com/weblogs/viewpost.jsp?thread=197203 "The keynotes had a strong educational theme: on Saturday morning Adele Goldberg gave a passionate plea for improvements to the USA's educational system. 40 years ago, US education was #1 in the world; today it is #19. The public school system is stuck in a complete political gridlock; changes are nearly impossible to make due to the many constraints imposed on schools by federal regulations, fearful and litigious parents, bullying, lack of funds, and many other depressing factors. It also seems that most uses of computers in the classroom have turned into disasters: the well-meaning geeks behind many school computer experiments don't understand the situation in the average classroom. For example, computers show up without sufficient power, are likely to be stolen, or locked up in a safe rather than being used! Schools are in total fear of the internet, which is seen as a source of pornography and influences of the devil. I hope Adele will put her slides on line, there was much interesting data." What a far cry from "computer programming for everyone". :-( I guess I really haven't given Python3000 much thought because it seemed always such a long time away; looks like it is finally coming to fruition. Another good time for any incompatible changes (if needed) to allow "edit and continue". --Paul Fernhout Dethe Elza wrote:

On 30-Mar-07, at 9:13 PM, Paul D. Fernhout wrote:

...

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).

Factor looks interesting. You also might be interested in Io:

http://iolanguage.com/about/

<quote>Io is a small, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self (prototype-based), NewtonScript (differential inheritance), Act1 (actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).</quote>

Despite the fact that Python isn't listed as an influence on Io, I find it has a bit of a pythonic feel, with the difference that prototyping brings. It has bindings to a rich set of external (mostly C) libraries (async sockets and dns, SQLite and SkipDB (embedded transactional databases), regular expressions (Perl 5 compatible), xml/html/sgml parsing, md5, sha1, zlib, lzo, blowfish, curses (text interfaces), OpenGL/GLUT, PortAudio, FreeType (TrueType antialised font support),Objective-C bridge. And, one of my favorite things, it has Erlang-like messaging and scalable (non-thread) concurrency. Not quite ready for prime time yet, but very interesting to keep an eye on.

...

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

Well, the herring is probably the OLPC, which Guido is working to support by implementing edit and continue, according to his blog:

http://www.artima.com/weblogs/viewpost.jsp?thread=197203 <quote> The software is far from finished. An early version of the GUI and window manager are available, and a few small demo applications: chat, video, two games, and a web browser, and that's about it! The plan is to write all applications in Python (except for the web browser), and a "view source" button should show the Python source for the currently running application. In the tradition of Smalltalk (Alan Kay is on the OLPC board, and has endorsed the project's use of Python) the user should be able to edit any part of a "live" aplication and see the effects of the change immediately in the application's behavior. (A versioned document store will make it possible to roll back disastrous changes.) This is where Krstic wants my help: he hopes I can work magic and implement this feature for Python. I got started right away during the conference, with a reimplementation of python's reload() function that can patch classes and functions in place. Even this small component still has a long way to go; a checkpoint of the work in progress is checked into subversion as part of the Py3k standard library. That's not where the rest of my OLPC work will show up; they use GIT for source control, so I will get to learn that. </quote>

At least, that's what it looks to me like he's saying, and he said much of the same thing on this list when he posted an improved reload module that he said was a simpler version of the one he was working on. Maybe it won't be as powerful as Smalltalk's edit-and-continue, but it might end up being the 80/20 solution to the same problem.

Now if I could just get him to take concurrency seriously (and the only serious approach to concurrency that seems to be workable is what Erlang does).

--Dethe

"...our universities, I suggest, are not half-way out of the fifteenth century. [...] The three or four years' course of lectures, the bachelor who knows some, the master who knows most, the doctor who knows all, are ideas that have come down unimpaired from the Middle Ages. Nowadays no one should end his learning while he lives and these university degrees are preposterous. [...] Educationally we are still for all practical purposes in the coach and horse and galley stage." H. G. Wells

I think we actually need to compete, not to shrug and hope the best platform wins. The fact that Python has the momentum it does with its rather laid back attitude toward evangelism is a testament to its strength as a platform and a community. I don't think that excuses us from trying much harder to make a strong case for it, though. On 4/1/07, kirby urner <kirby.urner@gmail.com> wrote:

I think Python thrives best in a diverse ecosystem of languages. After all, if it's to serve as a "glue language", there need to be languages to glue to besides Python.

An interesting argument. However, I've long since stopped thinking of Python as glue, and beginners surely aren't interested in learning multiple languages.

You mention PHP, but don't forget about Plone. We've gone far beyond the cgi days, where primitive Python works well, to more ideas about stuffing ZODBs with Objects that have all these view-related aspects -- strong model-view-controller designworks.

Nevertheless, kids who take up programming outside of school tend to be doing PHP, Flash or Javascripts, don't they? What would Dijkstra say to that? ) "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." -attributed to E. Dijkstra (I'm not sure he'd have much good to say about Zope/Plone either, but that's neither here nor there. The administrative hurdles to setting up a Plone site exclude most casual beginners. There is surely, roughly speaking, some best way to teach programming, and it deserves a lingua franca. We all learned the same fundamental mathematical notation, even though many others are not only possible but in common use by specialists. Should the same not be true of algorithmic notation (i.e. programs)? Either Python, (i.e., reasonably close to an optimum) will prevail or some damned QWERTY nonsense (not designed for nonspecialists) will prevail for another generation. Probably Java. Which leaves the impression that CP!4E. Which I hope we all agree is unfortunate.

Lists, dictionaries, top level functions and objects, a concise model of the OO paradigm... __rib__ syntax.

A honking great idea, to coin a phrase. Let's have more of those, please. mt