FWIW the <a href="http://software-carpentry.org">http://software-carpentry.org</a> team have done some excellent work on teaching scientists how to code. 'Data-carpentry' seems to be topical for them (looking at the twitter feed).<div> </div><div> <div><div> On Tuesday, 13 May 2014, Konrad Hinsen <<a href="mailto:konrad.hinsen@fastmail.net">konrad.hinsen@fastmail.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Matthias Felleisen writes: > > Note however that I didn't look at performance, which is not > > really important for most of what I do. > > In hindsight that is obvious from your use of Python :-) It should > have clicked in me, but I am just so used to think "scientific > computation ~ simulations of nuclear bombs, aircraft wings, oil > platforms, and such" and that's when performance is the overriding > concern. That's a very common misconception. High-performance computing is the most visible part of scientific computing, but not what most scientists write code for. Mundane tasks such as file format conversion take much more of our time. That said, it's interesting to look at why Python became such a popular language in science. Python code rarely has great performance, but Python makes interfacing to C and Fortran code very easy. Most domain-specific scientific libraries for Python have a C library at their core. One reason for this simplicity of interfacing is Python's reference-counting approach to garbage collection. In many scientific applications, the bulk of the data is held in NumPy arrays, which is just a C/Fortran array plus some bookkeeping information for Python. Both sides can work on the data, with no copying and no access restrictions due to garbage collection. The price we pay for this is of course the dangers of C and its explicit memory management. I'd really love to get away from this (and I know I am not alone), but there is no GC-based language yet (as far as I know) that is convenient enough for scientific computing. The most frequent problem (also in Racket) is GC ruining performance for short-lived small data items (think of complex numbers or points in 3D space). Even if the GC overhead itself is small with a good generational GC, GC tends to prevent other code optimizations that are crucial for performance. Konrad. ____________________ Racket Users list: <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> </blockquote></div></div></div> -- Sent from Gmail Mobile