I can relate to this. Nothing is more disappointing than putting together a nice piece of code and then seeing it run too slow to be practical.
A while ago, I wrote some physics simulation in Python. The code turned out to be really neat and quite idiomatic Python code. The code ran very slow, I was seeing only 10-20 frames per second when I was shooting for something closer to 120 frames per second. All I was doing was simulating a cube suspended on a plane with four dampened springs, and I was only simulating one of those where I wanted lots of 'em.
The problem was that my code was allocating and freeing way too many objects. The proper solution would have been to go from a neat idiomatic approach where the code resembles the mathematical equations it simulates to some kind of structure of arrays -style code with Numpy. Needless to say, there isn't much fun in using Python that way, so I might as well write the damn thing in C.
Later I went on to rewrite that code in C and running it on my GPU with OpenCL. I did write it in a structure of arrays style, so maybe the Python experience gave me a valuable lesson. Now it runs fast enough for my purposes.
With a decent implementation you can write performant code in a dynamic language.
An example in Common Lisp using the SBCL compiler on an Intel Core2 Duo @ 2.66GHz w/ 6G of RAM:
CL-USER> (defparameter *nums* (make-array 3000000 :element-type 'float :initial-element 0.0))
*NUMS*
CL-USER> (dotimes (i (length *nums*)) (setf (aref *nums* i) (random 30.0)))
NIL
CL-USER> (time (reduce #'+ *nums*))
Evaluation took:
0.375 seconds of real time
0.379975 seconds of total run time (0.379975 user, 0.000000 system)
[ Run times consist of 0.197 seconds GC time, and 0.183 seconds non-GC time. ]
101.33% CPU
1,000,511,208 processor cycles
96,010,096 bytes consed
4.4951772e7
CL-USER>
C isn't always the answer (thought it often is a pretty good default).
I think it's naïve to speak of "performant code" in general. Sure, I used SBCL (and CMUCL, and AllegroCL) to get blazing double-type single-cpu performance. But then I wanted to make use of multiple cores, which is when I ran into a brick wall. Things are better with SBCL now than they used to be, but people still run into bugs related to multithreading, not to mention that CL has little support for concurrent programming.
The definition of "performance" is different for every application. For some, it's multiplying long vectors of doubles. For others, it's making use of 16 cores for complex data structures operations. For others it's about servicing tens of thousands of mostly idle TCP connections (tried to do that with AllegroCL, failed). For others yet, it's about achieving consistent response times, which means concurrent and nearly pauseless GC.
In other words, choose the right tool for the job.
However I think the OP was comparing dynamic vs static languages. Ey made a prototype physics simulation in Python whose source code was nice to read but performed terribly. Ey then decided to write it in C (not a bad choice mind you).
It seemed to me that the OP found the readability of Python (and dynamic languages in general) a useful trait to have while lamenting that their implementations were too slow to be practical for eirs purposes.
Therefore I proposed an example of a dynamic language with the property of being easy to read while being fast in implementation.
I've used Qwt for decent results. It may be very heavy if you're not already using Qt, though, and the way its 2D plot is implemented makes it unusable if you need to update your data many times per second (I eventually just put my data in a texture and displayed it via OpenGl, doing the scaling manually). Another solution is to call gnuplot, matlab, or whatever through the command line.
Too many developers are paying way too much attention to the code being "nice" or it being in a "nice" language, and not enough attention to "does it work" "is it fast".
The problem is that when working with prototype code, you want to be able to understand what's going on. Code in structure of arrays style is harder to read. It would be nice that it would run with at least some kind of performance that's even close to what you need in the end.
We definitely need "nice" languages, because they give a huge productivity booster over writing stuff in C or other low level language.
However, many nice languages tend to be implemented using an interpreter, a crappy garbage collector and a giant lock to prevent anything with threads. This makes them unwieldy for applications where latency or throughput is important.
Recently the trend has been towards languages implemented with a compiler, using smart static typing disciplines and an LLVM-based backend. This is a very positive and welcome change.
Nice code is maintainable code. High-level languages exist for the sole purpose of making code "nice."
You pay enough attention to "is it fast" and you'll find yourself writing everything in assembler. There's a time and place for that, sure, but when you have a high level language that can theoretically optimize idiomatic code into something faster, it should opt to.
You pay enough attention to "is it fast" and you'll find yourself writing everything in assembler
Not everything. Not even then. Just the good bits maybe. Sometimes none of it. It might make me prefer C# over Java for example, because C# can lay down structs linearly in memory so I can throw them to the graphics card directly. Or maybe I'd do all the hard work in C and SWIG it so I could use Ruby.
But what I certainly wouldn't do is attempt to write a physics simulation in python, "idiomatic" or not.
"But what I certainly wouldn't do is attempt to write a physics simulation in python"
Depends on whether performance is a hard requirement or not - I've written engineering simulations of parts of power stations (including one nuclear plant) in Lisp and they weren't particularly fast but nobody bothered because they weren't used interactively.
Eventually I did write Lisp to generate C++ code for the same models when we did want better performance and it worked really well - but I only did that as an optional step when someone needed the extra performance.
But that's the thing - I would argue that NumPy code is not "idiomatic" Python which uses built-in operations/structures, like list comprehensions, tuples, and dictionaries. I had a similar experience during extensive NumPy coding where I thought, why am I not just writing this in Fortran.
Depends on what are you working on and what's the goal. I'm frequently on call for maintenance of a distributed system. During review I often return code that is not nice enough. Where "nice" means "will I understand this at 3am, seconds after I get woken up". I couldn't care less if it takes twice as long to execute. (please don't confuse it with not caring about complexity though - I do care if it's N^2 and doesn't need to be)
This doesn't mean it's not fun to wrap some long function into a reduce of a list comprehension. That goes into my fun projects, not stuff that's supposed to run 24/7 and worked on by others.
A while ago, I wrote some physics simulation in Python. The code turned out to be really neat and quite idiomatic Python code. The code ran very slow, I was seeing only 10-20 frames per second when I was shooting for something closer to 120 frames per second. All I was doing was simulating a cube suspended on a plane with four dampened springs, and I was only simulating one of those where I wanted lots of 'em.
The problem was that my code was allocating and freeing way too many objects. The proper solution would have been to go from a neat idiomatic approach where the code resembles the mathematical equations it simulates to some kind of structure of arrays -style code with Numpy. Needless to say, there isn't much fun in using Python that way, so I might as well write the damn thing in C.
Later I went on to rewrite that code in C and running it on my GPU with OpenCL. I did write it in a structure of arrays style, so maybe the Python experience gave me a valuable lesson. Now it runs fast enough for my purposes.