In a message of Wed, 14 Nov 2007 03:53:18 +0100, Jacob Hallén writes:
<snip>
>> So I'll definitely complain if you spend a lot of time on Ruby (or
>> Smalltalk for that matter) before Python's all the way there. I think
>> that'd be a bad idea for a whole range of reasons - get the last 10%
>> done for Python first before you take even more on your plates. We all
>> know that last 10% tends to be the hardest part. Focus is important. If
>> you can't make that work for Python, you'd have a hard time making it
>> work for any other language too (or convincing people that you can). Of
>> course I realize I have no real voice in this project, but that's my in
>put.

I don't think you understand the state of our project.  There is
practically nothing left that is 'python-centric' left to work on,
unless you have a burning desire to have the 2.5 features we don't
have yet, which is scheduled to get finished next week anyway.  This
is hardly any work.

Where we need work is to make the thing run a lot faster.  So, better
gc, more work on the JIT -- and play better with c-extensions, and
enable us to use the stackless transform on CLI and JVM, and the
generated JIT on that as well.

All this stuff is translation level stuff.  Thus it is relevant to all
the app-level input languages we support, not any particular one.
Speed up one, you speed up them all.  It took a 10 day sprint for some
of the pypyers and the squeak experts at the SCG to get Smalltalk up
and running. http://pypysqueak.blogspot.com/ Assuming we could find a
small group of similarly competant ruby language experts, we ought to
be able to do the same thing in the same sort of time range.  If we
cannot find them, and have to do it all ourselves, it will take
longer, since we aren't experts on the arcane and obscure details
about the ruby language that only ruby wizards know.

And then we can take Tim Bray's money and give him the fast ruby he
wants by working on precisely the same things that will give you the
fast python you want.  So I don't see why you aren't up in the front
row cheering these developments as loudly as you can.  Right now the
most promising path to get you what you want, which I see as a fast python
that is production-quality and suitable for deploying Grok web apps,
runs hand in hand with Tim Bray's desire for a fast ruby that is
production-quality and suitable to deploy rails apps.  You guys want
the same thing!  You don't even have to squint!  Why aren't you
cheering?

Laura

_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev

Reply via email to