And, in some ways, PyPy. I still think it is the sanest way to implement Python.
It makes me sad that I have to write C to make any meaningful changes to Python. Same goes for ruby. Rubinius was such a nice project.
Hacking on schemes and lisps made me realize how much more fun it is when the language is implemented in the language itself. It also makes sure you have the right abstractions for solving a bunch of real problems.
It is restricted in a way that you would restrict yourself to write high speed software in most languages, and I found it is not that restrictive compared to C that you would have to use if you were to write a fast Python library.
oh for sure, but I still feel like telling people pypy is written in python is misleading. it's written in something significantly like python, but it's not python.
The fact that it's written in python is often brought up in order to explain its name. But really, it's much less interesting than the fact that it has a tracing JIT. If it were called PyJIT I'd bet it would be clearer and more obvious that it's fast. And people would prob get less hung up on the distinction between python/rpython.
Oh hi! Thanks for posting. As I wrote this I wasn't sure if it was enough of a post. Let me know if you wanted to hear about anything else that seemed missing.
Preface: I am not a compiler engineer at all, so I'm just spitballing silliness here.
Avoidance of type feedback counters and such. Get LBBV to clean out the redundant type checks (Higgs proved this well, avoiding something like >90% of them) and produce a format, perhaps a high-level bytecode or just an HIR, that can be used as an input to start a method-level JIT compilation.
So, LBBV gives the quick and easy basic block compilation and cleans up the very easy stuff but leaves enough information so that a follow-up compiler can still use it as input.
