[racket] Blog post about Racket

On Tue, May 13, 2014 at 09:53:27AM +0200, 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.

There's Modula 3, which is not nearly as well-known as it ought to be.
It is type-safe, garbage-collected, object-oriented (as well as 
traditionally procedure-oriented), and doesn't have any significant 
overhead for complex numbers.  Complex numbers simply don't need to be 
stored as separate garbage-collected objects, any more than integers 
do.  It interfaces well with Fortran and C.

You mark modules as being UNSAFE, which allows you to use UNTRACED 
pointers to non-garbage-collected storage (such as that used by C and 
Fortran).  Of course, when you do that to a module, you can evade 
type-safety as well, which is why it's normally only done when it's 
absolutely necessary.

See the links in its Wikipedia article for details.

-- hendrik