[pypy-dev] Re: Comments from an observer

[Ben.Young at risk.sungard.com]

Hi Michael,

pypy-dev-bounces at codespeak.net wrote on 08/12/2005 22:09:09:

> This reply is solely to make a couple of points that I don't think
> have been made yet -- I don't want to give the impression that those
> points were less important that the ones I mention here.
> 
> Ben.Young at risk.sungard.com writes:
> 
> > Also, most people on #pypy seem to ask about using pypy to compile 
their 
> > simple python programs to c. Now, this doesn't seem like a great deal 
of 
> > work away (better error messages etc), but they are (politely) told 
that 
> > this is not what rpython is for. Now if rpython is not for this, why 
did 
> > you write PyPy in it?
> 
> Because we needed a description of the Python language that is amenable
> to analysis.  I hope this isn't a new answer to you...

I do understand that. It's just that as PyPy is a relatively complicated 
program it follows that rpython is good for making a lot of python 
programs amenable to analysis. (Yes as a by-product, but in my opinion an 
incredibly powerfull and usefull one)

> 
> > I don't want to come across like a moaner (and indeed, that's why I 
stop 
> > writing on #pypy as felt I couldn't be enough of a positive voice), 
and 
> > the only reason I'm writing this is because I think so much of the 
project 
> > and think it has so much potential. The last thing I want to see is 
for 
> > PyPy to become a great implemention with many powerful features, but 
then 
> > find that it had missed its time by not being "results driven" enough. 

> 
> What results do you want?
>

Sorry, I guess "results driven" came across slightly differently from how 
I meant it. I guess I meant that PyPy has many parts that with a bit of 
polish could be useable now in production based scenarios, as people keep 
asking about in IRC. I.e if people could write extensions, and PyPy was 
itself a bit faster and more polished then people could start using it 
now, and upgrade to a JIT version/different backend/thread model etc 
later. 
 
> > The world doesn't need another powerful research/university
> > language, it needs a great production language and with PyPy I think
> > Python could be that language.
> 
> Yes, but I want *Python* to be that language, with its multitude of
> existing libraries and useful dyanmism and all the rest.  Have you
> read this blog post:
> 
> http://dirtsimple.org/2005/10/children-of-lesser-python.html
> 
> ?  I think I agree with his point that supporting 80% of the language
> is of much less than 80% of the value.
> 
> If you have new code to write, then fine, writing it in RPython isn't
> that bad.  But it's the people who want to, e.g., use urllib2 or some
> old code they wrote last year that I personally am interested in
> helping, i.e. every single user Python has today.  This is why I'm
> most interested in the JIT and the standard interpreter end of things,
> not productizing an RPython compiler.  Now I'm not and wouldn't want
> to be speaking for the project as a whole, and I agree that
> productizing RPython would be a very worthwhile project -- but I'm not
> going to do it, sorry.
> 
> I hope that this has at least convinced you that I have no intention
> of PyPy being a research/university language, either.
>

You have convinced me, and I'm glad that you are all so passionate about 
the project. Again, I didn't want to come across as moaning, and I want to 
thank you for all the work you have done so far.

Cheers,
Ben
 
> Cheers,
> mwh
> 
> -- 
>   I never disputed the Perl hacking skill of the Slashdot creators. 
>   My objections are to the editors' taste, the site's ugly visual 
>   design, and the Slashdot community's raging stupidity.
>      -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq
> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 
>