Hi Albert, On Mon, Jun 17, 2013 at 11:20 AM, Albert Zeyer <alb...@googlemail.com> wrote: > I was wondering: Why is it that RPython is not a good general purpose > language? In the original paper > (http://rpython.googlecode.com/svn/trunk/doc/rpython-DLS08.pdf), it is > said:
RPython dates further back. It is perhaps first documented in the 2006 paper "PyPy's Approach to Virtual Machine Construction". In there you'll already find paragraphs like this: """ We should mention that restricting oneself to write RPython code instead of Python is still a burden, and that we are not proposing in any way that the Python language itself should evolve in this direction, nor even that RPython usage should become widespread. It is a tool designed with a specific goal in mind, which is the ability to produce reasonably efficient, stand-alone code in a large variety of environment. """ The paper you cite was written by an academic group that was focusing on OO languages (Java and CLI), building on the "variety of environment" concept. However the two paragraphs you cite feel a bit like advertisement today, given that interest for Java and CLI dried out in PyPy... Anyway, let's try to answer your questions in more details. RPython is great at one thing: being a language in which you express just the right amount of details in your interpreter for the purpose of turning this interpreter into a full VM automatically. For any other "more traditional" usage --- whatever the programming level --- there is another language out there that already exists and is much more well-supported than RPython in terms of features, tools, debuggers, group of people, etc. When people look at RPython, an obvious feature is that it is syntactically identical to Python. "RPython must be an easy language, given that it has got the syntax of Python, which is easy". This is a common misconception. In fact, pleasing the automatic type inference process can be difficult. It requires the programmer keeping in his head the global types of his whole program, and carefully writing code according to these implicit types. The process is much harder for newcomers, which don't have any written-down example to learn how to manipulate the types --- precisely because they are implicit. So this is the reason we are recommending against RPython now (and for many years now). Anybody who thinks RPython is as easy as Python is someone who will happily try out RPython and be burned alive by it. So "by default" we answer negatively to people who might be at the level of newcomers, to keep them away from this in-house, not-easy-to-program, not-easy-to-debug subset of Python which we call RPython. Obviously, we don't think that RPython is completely bogus. It is a language with use cases, and probably the one language with the most advanced meta-JIT framework :-) But, at least, I don't want to spend three years of my time trying to turn it into an good language for everybody (and, likely, getting out only an ok-ish language). Personally, I find it far more interesting to spend three years of my time (or 10!) on other things, like giving a good alternative implementation of the full unmodified Python language :-) A bientôt, Armin. PS: if you go to the STUPS Group in Softwaretechnik und Programmiersprachen, you might find David Schneider still in Düsseldorf :-) _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
