[racket] Blog post about Racket

This is not a misconception. It's an understanding based
on spending 15 years next to a top-10 department in scientific
computing, in a computer science department that was spun off
from that department, and a huge research group in the latter
that supported the former. 

What has changed is the world and what it calls scientific
computing :-) 

Having said that I know that the above-mentioned group have
moved to Java and claim to get decent performance -- but their
programming style is, well, peculiar. 

-- Matthias




On May 13, 2014, at 3:53 AM, Konrad Hinsen wrote:

> 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.