[racket] Blog post about Racket

FWIW the http://software-carpentry.org 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).



On Tuesday, 13 May 2014, Konrad Hinsen <konrad.hinsen at fastmail.net> 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.
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140513/2dff69ee/attachment.html>