See the PyPy JIT In Action 109
derGoldstein writes "Project PyPy is an alternative implementation of Python, with the main advantage being a Just In Time (JIT) compiler which speeds up your code considerably. They've announced the first public release of jitviewer, which is a visualization tool that helps you understand how your code is being compiled by PyPy's JIT, all the way down to assembly. If you just want to see how it looks and play with it, they've set up an online demo — just select a file, and click 'Show Assembler.'"
Re:Go Pypy! (Score:3, Insightful)
The language is readable, flexible, succinct, expressive and beautiful.
I hear it cures cancer too. Oh wait, that's Ruby. (Actually, I love Python, but I'm allergic to fanboism...)
Re:Go Pypy! (Score:3, Insightful)
Python is not going to make Java irrelevant. Sorry. I know it hurts to be told that your religion will never become universal, but that's reality for you.
Certainly one reason for choosing Java over Python today is performance. Python is relatively slow, and sometimes throwing more hardware at the problem is not an option, and rewriting stuff in C (like Python fanboys always suggest) is not actually that easy (and brings with it all the problems of writing anything in C -- there's a reason we want to use Python or Java in the first place, right?)
But performance is only one of the reasons. The kinds of organization that choose Java appreciate a number of things it provides that Python, by design, will never provide. Such as static guarantees of any sort, or the ability to enforce the separation of public/private APIs rather than relying on "convention". (No, Python fanboys, reflection in Java does not subvert all access checks.)
There are entire classes of Python bug that are simply impossible in Java. Passing the wrong object type as a parameter. Accessing a non-existent variable because you made a typo in the name, or because you forgot that Python does not have lexical scoping. And so on. If your developers are not all the most brilliant hackers in the world -- as is the case in most Java shops -- these things are problems with Python. (No, fanboys, unit testing is not a substitute for type-checking and variable declarations. Hint: if your developers are not wonderful developers, they probably aren't wonderful test writers either.)
Python is great for small-scale projects or for enthusiasts, and it can be used for large-scale projects where you have a small team of highly-skilled developers, but those are not the markets Java is used in, and performance is not the primary reason why Java is used in those markets. After all, if all they cared about was performance, they'd use C++.
Re:Go Pypy! (Score:2, Insightful)
You're argument only makes sense if you accept that the python language design requires dynamic typing. And this may (may) be true for the really advanced and esoteric uses of python, but anyone who's ever built a tiny compiler knows that 95% of python can easily be implemented statically typed. It would be a great exercise to try to fully inline the entire python runtime library to cover the remaining 5%.
Personally I'm convinced that a statically typed python supporting 90% of common use cases, and the IDE and tools that are possible to build using such a language would blow the regular python out of the water. Python's "dynamic" typing is in reality no more powerful than inference + splitting (ie. if you do 'x = 5; print x + 1; x = "boe"; print x + "1";' translate to 'x = 5; print x + 1; y = "boe"; print y + "1"', and split the variable name when re-typing occurs). And is there anyone here claiming that java's ctrl+space wouldn't be a great help in writing library intensive python code, never mind all other refactorings ?
I may understand in practice why people use dynamically typed languages, but theoretically there is no good reason for using dynamic typing at all. Furthermore python's "garbage collector" is so extremely basic it could simply be moved to compile time (I mean that there is no theoretical problem predicting all allocations of a python program at compile time, so (if you had a year to get this right) you could make python object allocation compile to a nop.