Paul deGrandis wrote: > I have stayed quiet thus far but I wanted to make sure everyone knew I > was still around and thought I'd contribute to the discussion now. > > I have been asked to give the same PyPy talk three times in the > Philadelphia area, and everytime I give a talk based on some of mwh's > slides, much to the same tune that Chris was singing in his email. > > The fact alone that PyPy team members are ABLE to go to different > companies with different interests and pitch the same product is > AMAZING and shows the strength of of the project and product that > everyone has helped form, shape, and create.
Let me make it clear: I think PyPy should work for multiple languages. I also think PyPy has accomplished an amazing amount of amazing things. What I am debating is the way to go about getting where you evidently want to go now: to be a generic system that can support multiple languages. I believe the best way to go there is to make it work, and by that I mean really work, for one language, which I believe should be Python. What does it *mean* when I say: PyPy should really work for Python? I believe PyPy will really work for Python as soon as it makes sense for some users to actually use it in some circumstances. More sense than using CPython, IronPython or Jython. Why do I think this should be the focus? There are two reasons, one marketing related and the other one software-engineering related. The marketing reason is that you'll have a much much much more easy sell of generic PyPy technology once someone is using it in production. The other marketing reason is developer marketing: once you're using the technology in production, you'll get more developers motivated enough to improve the underlying technology. More mindshare. The software-engineering related reason is that you will find out, and solve, the last details only when you actually try to use the software for serious purposes, i.e, in production. If you expand the scope of your project too far before it works well in one particular case for actual people, you run the risk of never getting to those details. Those details are very important. You need to restrict your scope to get that far, before you widen your scope again to take on new challenges. If you don't restrict your scope you're in serious risk of losing your way. (I know this probably sounds like vague handwaving to you. I guess the original wiki is the best resource I know of distilled software engineering wisdom.) > Let people say what they want. Personally, I don't think Tim's blog > was harsh, and anyone who has spent ANY time on the Internet can > clearly see through the comment (and recognize it for what it is). I don't think Tim Bray's blog was harsh either. I was just disappointed some of the technology wasn't highlighted and was curious about how that had happened. The (harsh) comment to that blog I believe cannot be countered by spending time on the Internet: you won't find any people who are using PyPy interpreters in production. Before that it's hard to determine from the outside whether the project succeeded or not, if you at least take the PyPy project as a project to deliver production-ready interpreters at all and not just a research project. Again, I'm not trying to criticize what the project has already done. I'm trying to be a voice of pragmatism and the voice of a potential open source end-user. Listen to me if you like; it's not an enemy voice. There are two PyPy technologies that I can see that are close to pragmatic fruition now: * writing CPython modules in RPython (I completely lost track of what the state of this is since there have been a lot of changes) * running a Python interpreter that is in some ways better than an existing one. I was under the impression that this was supposed to be the more central focus of the project, not RPython. You know, "The PyPy project aims at producing a flexible and fast Python implementation.", what it says on your web page. Being a generic platform for interpreter developers or creating a pragmatic Smalltalk or Ruby interpreter are not close to fruition right now. The debate is now whether taking on those goals *now* will also further the goals above. Laura thinks it will, and I think it won't. (I think it'd be great to take on those goals later.) Besides accomplishing your goals there is of course also the matter of financial survival for the project. If you can sell your technology at all that's a plus for survival. I'm leaving finances out of the picture and you can argue I shouldn't. If we bring them into the picture, you can sell to me the idea that taking on more will help the survival of the project, and otherwise *nothing* will ever get done. You can't sell to me that this is actually good from a pragmatic software engineering perspective (where you want to bring projects into production), or from an open source project perspective (where you want to attract contributors who find your platform of use). Regards, Martijn _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
