[racket] article about Racket

On 11/11/2011 08:43 PM, Neil Van Dyke wrote:
> Raoul Duke wrote at 11/11/2011 09:59 PM:
>> 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."

One thing that tends to make DSLs work so well in Racket is that they 
all can work on the same data model.

In every programming job I've had, there's been at least one home-grown 
DSL that someone invented to solve a problem more easily. In every case, 
the biggest pain involved wasn't learning new syntax or semantics, it 
was getting the dumb things to work with the other tools we had.

On the other hand, in Racket, I'm usually using three DSLs or more in 
any given program - that's counting "small DSLs for big wins" like the 
`for' macros, and the one or two DSLs I've written to solve my problem. 
It's usually not hard to share data among them, or to get them to work 
together.

FWIW, it's not just that the DSL support in Racket was written by really 
keen peeps, but a lot of the DSLs were as well, and were the subjects of 
research papers. A lot more thought has gone into them than into most 
DSLs. On the whole, they do a good job teaching by example how to write 
a good DSL.

Neil T