[pypy-dev] pypy on Tim Bray's blog

[Martijn Faassen]

Laura Creighton wrote:
> 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.

Your Python-centric work is not done until I have a serious shot at 
downloading or building a PyPy-based interpreter, run it on top of 
*some* backend, and can start porting, say, Zope 3 on top of it. Or 
Twisted. Or lxml. Or Pygame.

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

I'm well aware that lots of the work is there. But there are multiple 
ways of going about making this work. You can take on projects of a 
large magnitude such as the implementation of new interpreters, or you 
can focus on making it work right with one-and-a-half interpreters 
first, i.e. a Python one + a few proof of concept ones.

Both will involve sacrifices to the project. If you take on another 
interpreter project, you'll sacrifice the ability to get anything in 
production in the foreseeable future. If you take on just Python (and a 
half), you'll sacrifice some of the generic nature of PyPy's work, at 
least for now, in the face of expediency.

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

I've been programming for a while too, you know. I don't buy this. You 
can't continue to *always* solve the generic problems without any 
consideration for an actual production goal. If you want to write a 
generic system for X, the way to go about it is not to take on different 
projects A, B, C, D and E equally. The way to go about it is to think 
about all of these projects, start off generic and keep it in the back 
of your mind, and then focus on getting project A to the end of the 
road. After this works reasonably well and people are using it and 
giving you feedback, you expand the breath again to B, then C, then D. 
If you start B before you finish A, or give all equal weight, you'll 
flounder around indefinitely.

So far I think you've been doing this right. You've been focusing on 
making a Python interpreter work primarily. Other interpreters in 
RPython work too, but you haven't put a major push behind any one of 
them, just got them far enough to experiment with smaller cases, and 
prove some basic concepts there. The main focus has been Python.

But it isn't there yet.

> 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/ 

Yes, I read that. It's cool work. And there's not a single real-world 
Smalltalk program in the world you can run on top of that today, right? 
How much more time and effort do you think it will take to get that far? 
  How much more time and effort before it would it actually make *sense* 
for a Smalltalk developer to do so?

I'd like to find out the same answer for Python, too. When do you start 
recommending a PyPy based interpreter as equally good for production-use 
(in some circumstances) as CPython, or Jython or IronPython?

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

You'll be able to do a proof of concept in a short amount of time. 
That's all.

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

Because I think I know how to finish software development projects, and 
because I see danger signals.

> 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?

Because if you take on anything bigger than a proof of concept for Ruby 
now (and even that is a lack of focus I don't think you can afford), I'm 
pretty sure I can wait a few years more before I can do that.

Again, I'd be happy if you proved me wrong. I'm just giving you my 
perspective. I'm not speaking as a customer, and I know there's money 
involved and that's part of the real-world concerns of the projects too, 
but I am speaking as a friend.

Regards,

Martijn