| >Python is much slower than C and many other languages, however most of the time speed is unimportant. When it becomes important, there are many technologies to mitigate the problem in your "hot loops." I'm not convinced by this "speed is unimportant". Well, if you're writing shell scripts in Python/Ruby etc, OK, it might be. It might not even be important in web programming. But for using any language as a generic programming language speed is very important. The reason you cannot build full blown desktop apps like a browser or GUI libraries in Python? Lack of speed and memory control. And yes, you could offload the work to some extension. And that's a barrier. Suddenly knowing Python is not enough. You got to also learn, e.g, C, and you have a segmented program structure, with some stuff here and some stuff there. Or you relegate Python to just the scripting layer for your program and do the real stuff in C/C++ (like Adobe Lightroom uses Lua). I don't want to mitigate the problem in my "hot loops" with another language. I want to not have that problem in the first place. That would make me more productive. One example: imagine NumPy in pure Python. For one, it would be trivial to include in your project. Without building anything, it would work in all platforms. Second, it would be far more accessible to people that don't know C/Fortran/et al to hack it. Third, it would have been available for Python 3 or PyPy in a few months, not after several years. Alright. Now, another way of achieving better speed is parallelism. But due to the bad support for it (GIL, lack of first class support) it's not easy to achieve this in CPython/MRI. Sure, you could use multiple processes but then you get all the issues of handling them and synchronising them with your own ad-hoc solution, and without first-class support from the language. Which is a barrier. Yet another way to get more work done --for some kind of programs-- is evented code. So you have something like Node or Twisted. But Node doesn't have language support, so you get the "callback spaghetti" and Twister and co are external dependencies to the language, so they add another overhead. Again, barriers. People say "Speed doesn't matter" because they are trained by their language to only work on problems where speed doesn't matter. So it's more like a self-fulfilling prophecy. Or course, if you constrain yourselves in "convenient" domains that your language supports fast enough, speed doesn't matter. But every step out of this and you are in need of clutches, from C extensions, to Cython, to Psyco, to Numpy, etc. |