[racket] Blog post about Racket

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Sun May 11 17:24:28 EDT 2014

On May 10, 2014, at 8:42 AM, Konrad Hinsen wrote:

> Hi everyone,
> I just published a blog post about my first experiences with Racket:
>   http://khinsen.wordpress.com/2014/05/10/exploring-racket/
> Comments welcome.
> This is also a good occasion to thank everyone on this list who has
> helped me by answering questions during the last few months.

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. 

Here are some detailed comments: 

1. You write that "the hallmark of the Lisp family is that 
programs are defined in terms of data structures rather 
than in terms of a text-based syntax."

No! This is a common misunderstanding, and I beg you not 
to repeat it. 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. The Lisp method 
gives you naturally structured data; a compiler or 
interpreter can make sense of this data w/o much parsing  
effort. The Python method gives you "flat" unstructured 
data, meaning that implementation needs full-fledged parsing. 
But that's it. Other than that, you could use the exact same
techniques to execute the program. (And people do so.) 

2. Next you say "Racket’s macro system feels more like a 
programming API for the compiler." With this sentence you 
are hitting the nail on the head. 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. 

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. 

Scala definitely shares the academic group pedigree and 
differs now from Racket because Martin Odersky took a 
commercial time-out and placed Scala on a firm industrial 
grounding (which was possible due to the JVM anchor). 

But yes, these are all research labs. 

4. There are some generic data interfaces (see dictionary)
and generic operations but yes, Racket is more 'static' (in 
the sense of differentiating) than many scripting language. 
We have discussed making the successor of Racket (Racket II)
more generic and developing a hardening philosophy that helps
programmers inject the distinctions once they are happy with 
the result the way people are now encouraged to inject types
into untyped programs. The differentiations help programmers
discover bugs early but in a homogeneous domain such as matrix
calculations, this may not help and actually hinder. 

5. Next I don't know what I am talking about and I am off-line
so who knows how this will come out. You write 

> What I miss most is access to my data in HDF5 and netCDF formats. And the domain-specific code for molecular simulation, i.e. the equivalent of my own Molecular Modeling Toolkit. Porting the latter to Racket would be doable (I wrote it myself, so I am familiar with all the algorithms and its pitfalls), and would in fact be an opportunity to improve many details. But interfacing HDF5 or netCDF sounds like a lot of work with no intrinsic interest, at least to me.

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

6. In response to your assumption whether 

> given Racket’s academic and teaching background, it is quite possible that there are lots of students using Racket who find sufficient support locally that they never manifest themselves on the mailing list.

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 :-)
When I teach I tell them that they are learning 'design' and 
they don't know anything about Racket, which is true. We have 
local means to help students (mailing lists, blackboard, TAs). 

NEU is only one of many universities and high schools that 
use Racket. We estimate that to this day the vast majority of 
our 100,000 yearly downloads are educational and we are pretty 
sure that the very vast majority of them (up to an epsilon) 
never show up on the 'user' list, due to 'local' support. 


> Even though the Racket community looks small compared to other languages I have used, it is big and healthy enough to ensure its existence for many years to come.

That's the goal. And we need people like you to push Racket
forward. We really want it to be a wide-spectrum language 
both in terms of users as well as in terms of linguistic 
and software-engineering structure. 

-- Matthias

Posted on the users mailing list.