Hacker News new | ask | show | jobs
by dagw 1877 days ago
Nice prototypes which I then had to fix them or even rewrite to C/C++

Even as someone who 'knows' C and C++ I still find it faster and easier overall to do the exploratory and 'science' part in Python, making sure it works and gives me the answers I need in the format I want etc. only to then rewrite and optimize the slow parts in C or C++ if necessary.
1 comments
jhgb 1877 days ago
You could probably use something like Chez Scheme for that, especially the new Racket fork of it with unboxed flonums and flonum vectors, except with significantly decreased need to rewrite stuff in C for performance. Also with proper threads to boot.
link
dagw 1877 days ago
You're missing the point. What makes python 'fast' is that it comes with 'out of the box' support for everything I might need. Reading and writing obscure file formats. Every sparse matrix, image processing and graph algorithm I might need has already been implemented. Do I need to all of sudden solve an optimization problem or a differential equation? Already nicely integrated with the library using. If I need some obscure domain specific algorithm, there is almost certainly a library for that already. I don't have to worry about any of that stuff and can focus on solving my problem.
link
jhgb 1877 days ago
There's quite a few C/C++ libraries for those things, right? Integrating them with proper FFI (of the kind that Chez has, for example - or LuaJIT, for that matter) seems hardly difficult...although differential equations or optimization problems may be better served without any language interfaces whatsoever since they involve functional parameterization. That generally sucks with mixed-language solutions, to the extent that GSLShell, the LuaJIT interface to GSL, completely skipped the DE solvers in GSL and reimplemented them in Lua for higher performance. I imagine that 'fast' in case of Python really needs to be quoted the way you did.
link
kbutler 1877 days ago
"seems hardly difficult" and "could probably use" is seldom faster than "out of the box" and "already nicely integrated"
link
jhgb 1877 days ago
Maybe, but the latter definitely isn't the case with Python, especially in case of PyPy (or at least it wasn't the case the last time I tried that), so there's that.
link