[racket] DSLs and complexity

In my opinion, there are two kinds of DSLs: good ones and bad ones.

Good ones feel like you're using the programming language, but it has
been tailored to the problem domain. Your intuitions about using the
language still work in the DSL, and the DSL manages to fill in the
boilerplate that would be required if you were using the raw language.

Bad ones are so special-purpose that you almost have to forget what
you know about the programming language you're using to make the DSL
work. They're often works of art in terms of how they create their own
language, tailor-made to the problem domain. But in so doing, they
really do create a new language, with new rules, and new ideas to
absorb. Because there's so little transfer from the original language,
you might as well be learning a new language.

As a simple example, there are DSLs that try to let you use SQL in
whichever programming language you're using. Well, with all due
respect to the authors, if I wanted to use SQL, I'd be using SQL. If
I'm using a programming language to interface with a database, I want
the stuff the PL gives me--type checking, ease of testing, standard
function call behavior, etc. Instead of trying to make the PL I love
look like SQL, I want you to make SQL look like the PL I love. :-)

Just one (not very informed) person's opinion. Take it for what it's worth.
Todd

On Fri, Jun 21, 2013 at 8:39 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> On Fri, Jun 21, 2013 at 8:26 AM, John Gateley <racket at jfoo.org> wrote:
>> Subject for discussion:
>>
>> http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider#
>>
>> Interesting sentence in the middle:
>>
>> Consider DSLs, abstractions and the attraction to being the one to build a
>> framework that gets leveraged for years.
>>
>>
>> I think Racket is a different target: education vs. engineering (is this
>> true?).
>
> Racket is certainly targeted at software engineering -- we all do lots
> of it to build Racket *in* Racket, and people build complex software
> systems on top of Racket.
>
>> As a software
>> engineer, I really agree with the article. Complexity is almost always a
>> terrible thing,
>> whether it is a DSL, a complex implementation of a simple interface, or just
>> the
>> one additional thing requested by product management that didn't fit.
>>
>> For Racket: are DSLs a source of complexity? Or would you argue that they
>> reduce the
>> complexity normally introduced with DSLs?
>
> I agree with much of the article (and lots of could well apply to
> Racket) but I strongly disagree with what they say about frameworks
> and DSLs. The most fundamental tool we have in computing for managing
> complexity is abstraction, and DSLs are an enormously powerful form of
> abstraction. I'm unclear on why the author thinks that a DSL increases
> complexity -- perhaps the DSLs they've used have failed to genuinely
> abstract things, and required users to work at both the abstraction
> and implementation level. There, I think Racket does help produce
> genuine abstractions.
>
> Sam
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users