[racket] Blog post about Racket

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.