[pypy-dev] How to learn RPython as a general purpose language

[Richard Emslie]

Hi Josh,

Josh Gilbert wrote:
> 
> ## References
> I've found a comment on LtU suggesting that it is extremely hard to
> learn, yet a valuable skill if you can cut it:
> http://lambda-the-ultimate.org/node/1260#comment-13972
> 

I'm not sure I said it is 'extremely hard' or it is a 'valuable skill' - 
but i definitely said:

"""
Python is a subset of Python. The rules as to what the subset is vague 
indeed, but in short writing code without using dynamic language 
features post import time (ie the static-ness is based on code objects 
not python code) should be enough. These rules are fairly well 
documented and unlikely to change significantly in the future. The 
problem (IMHO) of promoting it is a language is that the tool chain is 
extremely non-user friendly and it is necessary to have a good 
understanding of how the flow graphs are created and how the several 
annotation passes work. All you will get is a stack trace in some 
obscure area of the annotation code for a compile error. :-) If one 
takes the time to learn how the above works then you have pretty useful 
language at your disposal.
"""

Well I wrote that many moons ago.  And is more or less still true - 
except I understood pypy's tool chain better than I do now.  After 
spending about 4-5 months rewriting a quite large application from 
python to rpython - I can say this about having a 'pretty useful 
language at your disposal':

(a) the translated rpython code was faster than python

(b) some parts were pretty much a copy and paste of the original python 
code and just a few tweaks to make it compile

(c) some parts were a complete rewrite

(d) the time taken for (b) and (c) was no less than it would of taken to 
write the code in say java or c++.

(e) the end result is still some nice python code that was still 
readable and easy to modify.

(f) a lot of niceties of using python go out the window such as no long 
waits for compiles, nice stack traces, run time introspection, no 
segmentation faults, etc etc

(a), (b) and (e) are advantages (c), (d) and (f) are disadvantages.  Of 
course if your application is interpretative and can make use of say the 
jit (and similar arguments for other features like the stackless 
transformation), then (d) would be a massive (colossal) effort that you 
get for free via pypy.  (f) does also have the advantage than rpython is 
python and during development one can run with some interpreter.

YMMV

Cheers - Richard