[racket] Blog post about Racket

> That said, it's interesting to look at why Python became such a
> popular language in science.

Coincidentally, I just read this article:
http://www.talyarkoni.org/blog/2013/11/18/the-homogenization-of-scientific-computing-or-why-python-is-steadily-eating-other-languages-lunch/

Not sure if this is your experience, but from the article and
comments, the summary seems to be that python is not great for any one
task but "wins" because it enables you to do a bunch of tasks in the
same language. Interestingly, it seems that Racket can do everything
in the article's list as well.


> 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:
>   http://lists.racket-lang.org/users