[racket] Blog post about Racket

Hi Matthias,

Thanks for your comments!

 > Hi Konrad, thanks for the post. It is quite illuminating because 
 > I wouldn't have thought that we're that close to 'performant' in 
 > this domain. 

I was a bit surprised as well, but I found that the math library
is really a pretty good foundation for scientific computing.
Note however that I didn't look at performance, which is not
really important for most of what I do.

 > In order to turn a Racket (Lisp, Scheme) program into Rackete data,
 > you to perform (roughly) the following actions: add '( to the
 > beginning of the program and add ) to its end. In order to turn a
 > Python (C, Java) program into a piece of Python data, you need to
 > add " to its beginning and " to its end. I am ignoring module or
 > package structure here.
 > 
 > The difference between those two methods is the amount 
 > of parsing left to the implementation.

I perfectly agree with that summary, but to me this difference is
very important.

90% of the people I work with do a lot of programming but have never
taken a CS course. Show them s-expressions, and they will immediately
see that this is something they could work with. Tell them to parse
Python code from a string, and they will stop listening. It's too far
from what they feel comfortable with.

BTW, there is another practically relevant difference: the Lisp family
gives programmers a well-defined hook into the compiler for
pre-processing specific expressions. Most other languages don't.
Python gives you the option of reading a whole module as an AST, and
then modify and compile it. But that's a lot of overhead and it
doesn't provide much flexibility because the parser limits the syntax
so much.

 > We don't think of Racket's syntax system as a 'macro' system and I
 > personally do not use the phrase. Instead I say 'syntax system' and
 > when asked I call it a compiler API.

I agree that the term "macro" should be banned, but I don't think I
can contribute much to that.

 > 3. Well, minor point but when you state that "I am aware of only
 > three other languages developed in a similar context: OCaml,
 > Haskell, and Scala." please do keep in mind that GHC is a Microsoft
 > product, OCaml comes from INRIA, which compares to a university the
 > way Versaille compares to a MacMansion in a Dallas suburb.

I know that the means behind these projects are very different, but my
point about the roots of the languages in academic research is valid
nevertheless. I'd like to see more of this.

 > Could you port your framework and use the FFI to get data
 > via some existing HDF5 and net CDF library for now? 

That's an interesting idea. For my own domain, I think it would be
much easier to interface the HDF5 library directly using the FFI.  The
reason is that everything written on top of HDF5 is written in Python,
whereas HDF5 is plain C. Making languages with different garbage
collectors work together is such a pain that I am not very motivated
to try. I guess this problem will ensure the survival of C for many
years to come.

An HDF5 wrapper using the Racket FFI looks definitely possible, but
getting it efficient is perhaps not trivial. The fundamental problem
is that the datasets being read and written are potentially huge. Any
interface that ends up converting or even just copying arrays of 2 GB
is going to be too slow for use in real life. If the FFI can provide
C-pointer access to something like a flvector, and ensure that it's
not garbage-collected for the duration of a C function call, then a
good interface should be doable.

 > We have separate educational mailing lists for instructors, 
 > and we never see any of the 300-400 students from Northeastern 
 > alone that use Racket on a semesterly basis. Most of these
 > students never figure out that there is a 'user' mailing list :-)

If they don't see a need for it, great!

Konrad.