PyPy 1.5 Released: Catching Up
morepypy.blogspot.com
morepypy.blogspot.com
I also recall reading PyPy's blog, especially a blog post about their Prolog based JIT prototype and I thought "wow, this sure seems like a complicated way to implement a JIT engine, I wonder if they will ever implement something that can run real code".
Fast forward to today and Unladed Swallow is dead and PyPy has implemented a Python implementation that's compatible with Python 2.7 and beats cPython 2.6 on various benchmarks. Pretty impressive and kudos to the PyPy team.
But I'm impressed that it actually runs my code, in contrast to the other alternative Python implementations I've tried.
Look forward to seeing more of sandboxed mode, which has been a much desired feature of CPython for many years now. And stackless mode. I just hope they can get the executable size and build times to a reasonable level.
i have never been so glad to be proved completely wrong :o)
I just wish Google would throw some support your way.
Although personally I actually wouldn't mind giving up one for the other, as that would allow PyPy to act as an extra incentive to drive py3k adoption in third-party libraries. Of course I understand if the PyPy developers don't just want to use their hard work as a gaming piece to drive the py3k adoption agenda, though :).
Edit: I guess this provides insights:
I have the plan to start working on the scheme implmentation.
The thing I don't really like about the project is that it has one name for two things. I can understand how that came about historicly but I think the should make two names out of it.
Care to elaborate?
It does have dynamic typing, but that's not what it means to be a "dynamic language". Dynamic languages are late-bound; everything is up for grabs at runtime. In standard Scheme, this is true in the fairly useless sense that everything depends on the bindings in the global namespace, so you could in theory (set! car somethingweird), but this is very rarely practical; it almost serves only to make optimizing Scheme compilers difficult to write. Aside from that, the language leans much further toward early binding, doing things at compile-time, and using efficient data structures at the cost of flexibility.
In Scheme you can define and create new functions and macros at runtime. There is not much else that is dynamic about the Scheme standard[1] because... there's not much else to the Scheme standard.
As for reflection, I see that mainly as a tools/debugging aid, and therefore very implementation-specific stuff. "Dynamic" languages have reflection in their definition because they are mostly defined by implementation.
That said, the Scheme standard doesn't preclude reflectivity at all, nor seems particularly compile-oriented to me. Nowhere it is assumed that implementations be compilers at all.
I think most of the things you find missing there were not left out for efficiency, but because it was rightly considered that they don't belong in the language spec at all.
[1] By the "Scheme standard" I mean R5RS.
> As for reflection, I see that mainly as a tools/debugging aid
You can use it that way, but you can also use it for metaprogramming.
> "Dynamic" languages have reflection in their definition because they are mostly defined by implementation.
Plausible.
> That said, the Scheme standard doesn't preclude reflectivity at all, nor seems particularly compile-oriented to me. Nowhere it is assumed that implementations be compilers at all.
True.
Clojure 1.2.0 is already faster than Racket. Version 1.3.0 will probably bring it close to Go territory on those benchmarks.
For my own work I've found that getting Clojure in the Java ballpark is certainly possible.
And who pronounces blue, blur?
Not agreeing with grandparent, though. Lots of people admit to playing with their Wiis for hours a day.