Martijn, Don't get me wrong, like Carl, without taking finances into account, I agree with you totally. As a software engineering major, I can also see most of your arguments from a purely engineering and practical perspective.
I mean, c'mon, who doesn't want to see PyPy offer you the ultimate Python experience. I don't know about anyone else, but that's what brought me to PyPy in the first place. I love common lisp and lisp macros, I like operating at different levels in a language to achieve elegant solutions, and I love python. I felt like PyPy could give this too me and more. Has PyPy been that for me? Yes and no. Like you I wish there was complete python support, but the architecture and abilities of PyPy as an infrastructure blow me away. It has potential to grow, stretch, and extend, in an elegant and sound manner, with little effort. It's hard to find such a system that is capable of that with sucha caring and vibrant community surrounding it. As a grad student working in academia and doing side projects, I do whatever I have to do to learn, better myself, and pay the bills. The perfect case is Summer Of Code. While working on the jvm backend, Drexel University secured me funding, resources, and a lab to do my autonomic computing research, and I'd be a fool not to follow it, even it meant shelving some things on PyPy for a bit. Financial concerns have become a part of PyPy, it's just the way it is. I appreciate your response and admire your passion for the project. By no means do I see contributions to this discussion as a threat or an attack. Regards, Paul On 11/14/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
