Hi Martijn, let me first note that I agree with a lot of your points, when not taking the financial side of things into account. I will ignore the financial side of things in this mail (since I don't think anybody proposes to focus on something completely different than our Python interpreter _without_ major financial incentives).
Martijn Faassen wrote: [snip] > 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) It's still working but mostly accidentally. It needs some rethinking and a rewrite. We have now better machinery and also ideas how to make it really fast, but it's a manpower problem. There isn't anyone interested enough in supporting this in the current PyPy team. If somebody outside the current PyPy-team really wanted this and were willing to work on it we (or at least me personally) would give him all the support we can. > * 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. Well, I guess what we really need to get adoption in this area is a reason for people to switch to PyPy's Python interpreter. Right now doing this means you get a slower Python, with less available extensions. Of course you get nice features like lazy objects, Stackless, transparent proxies, etc. But, it's not clear to me that these features are actually worth switching for anyone, after all there is no massive adoption of Stackless Python either (which has some of the benefits and lacks some of the disadvantages of PyPy). I guess one obvious candidate for something PyPy can provide but CPython will never be able to provide is the sandboxing work that was done recently. > 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.) Completely sidenoteish and beside the point, but: I disagree about that it's hard to get a pragmatic Smalltalk interpreter, since you only need to implement the VM (which we already did) and some primitives to get a good Smalltalk VM, since all the hard bits are done by the image anyway, and we don't plan to re-create an image but just reuse Squeak's. End sidenote. Cheers, Carl Friedrich _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
