[racket] article about Racket

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Fri Nov 11 22:43:56 EST 2011

Raoul Duke wrote at 11/11/2011 09:59 PM:
> certainly sounds cool and featureful.

Indeed.  The article might be a little overwhelming, since Racket has an 
epic buttload of support for DSLs, and the article has to merely skim 
past each topic before the reader is likely comfortable with it.

It may also helpful to know that the sum of Racket's support for DSLs 
represents calendar-decades of work by numerous smart people, and has 
been proven in practical use in various forms.  So this is not some 
academic curiosity, thrown together in a year, with a contrived example 
and lots of holes.  This support was created and refined, for and 
through practical real-world use.  (I'm speaking as an industry user; 
I'm not one of the developers of this support.)

> my knee jerk reaction is that i believe it is probably really hard to
> avoid making a language/dialect/syntax/extension/whatever that isn't
> doomed to be a horrible heckdom shoved onto the users. so the tools
> might let anybody do a new language, but the ability to use those
> tools seems to me to be a whole 'nother kettle of fish?

I think it certainly is easy to make a suboptimal language, and making a 
great language is difficult.

The Racket book I am writing will emphasize the everyday "small DSLs for 
big wins".  I'll also suggest "pervasive local DSLs" as an optional 
practice of style,  And finally suggest when "#lang" can be a big win 
(e.g., all-encompassing DSLs, non-programmer programmers, legacy code, 
language research).  There's useful places for all these kinds of DSLs, 
and the wins can be so big that we shouldn't say, "DSLs are difficult to 
do well, and we don't already know how to do DSLs well, so let's not 
learn anything new, and instead let's type tons of unmaintainable Java 
every day and drink ourselves to sleep every night."

> also my limited experience with dr. racket has never been much fun or
> impressive vs. "real" ides.

That's a topic for a different discussion thread, but... I'm guessing 
some factors that would affect this comparative assessment:

(1) How much experience and skill one has with each.
(2) What kind of work one is doing.
(3) What preconceived notions one has about how such work should be done.


Posted on the users mailing list.