Meetup 2: ROC Py

I went to ROC Py, the Rochester Area Python users group again this Tuesday. The talk this month was mainly focused around Bridging Python with other languages. The speaker outlined and demoed the use of python with languages such as C, Fortran, .Net and even Java. Overall I liked the talk, it was well delivered, gave a good walkthrough of the procedures of extending python and for the most part I was interested throughout the whole thing. Where I draw issue is with the concept of bridging libraries.

In my opinion, you should never bridge languages for anything other than a library. If you need to do some very fast computational procedures and you're considering writing CPython, your best bet is to just write it in C or C++. I don't care how familiar you are with Python and how much you love it, there's a rule with programming. You choose the right language for the right job. Python is good for simple scripts and other lightweight applications. Many people choose Python over C for simple programs because of its ease and readability. You sacrifice both of those when you start bridging Python with C. If you need to do things very fast, just use C or C++, please.

The exception to the rule here is libraries. Why? because sometimes you need to do something that's just not exposed to your language without going deeper. For example I had to write a native plugin to Unity and I used C++. I've also written android plugins and for that I used Java. Why did I do this? Because Unity C# simply can't access DirectX and OpenGL the way I needed to. This was a plugin to be distributed next to Unity, not as a core part of a project. If you wanted to write an OpenGL layer into Python (for whatever reason) fine, use CPython, but even in that case I see C being a better option overall.

Something like Jython or IronPython (Python in Java and C# .Net respectively ) I understand a little bit better. Jython compiles down to java classes which should make it about as fast as Java on the bytecode level, but I doubt that the compiler is really doing a good job of optimizing that Python so the speed may not be actually as fast as Java in practice. IronPython is pretty much the same but .Net compiles down to machine code. Again the compiler optimizations are going to matter here so you may not quite get the speeds you'd expect from C# or VB. At least with Jython you keep the portability of Java but IronPython I don't really get. I don't really trust the Mono compiler all that much and Mono runs in a VM outside of Windows so you'll be taking a performance hit even further.

At the end of the day it doesn't seem like speed is going to be a big enough gain to offset the complexity of bridging Python to another language. I think it's a better idea overall to use Python to what it does well.