But Seriously Cosine, Just Define the Freakin' Term Already!

chromatic on 2007-08-16T21:12:31

I suspect the reason many Perl enthusiasts do not agree is that they have never written a language-powered DSL in an appropriate situation. If the most vocal Perl users (and their leadership, too?) is lambasting the idea, they certainly have no small social obstacle to get around if they honestly think the language-powered DSL is the right way to go.

— Cosine Jeremiah, Why Use a Language-Powered Domain Specific Language?

I'm lambasting the idea that, because Ruby lets you slap colons on the front of words and call methods without wrapping their arguments in parenthesis, you're somehow the Mayor For Life of Deeesselltown. Woo. Party time.

Honestly, I can't tell what the difference is between an API (How old school, you crotchety old Perl programmers are still writing APIs? I bet you ride your dinosaur to school uphill both ways in the snow, don't you GRAMPA!) and a DSL (Ruby will buy you a hoverbike. Ruby loves you. Ruby makes its own gravy.), except that maybe somehow string-eval is the magic pixie dust that require or use (Gah! How '90s! Totally tubular old dude!) or do (WTF?! I don't see code blocks anywhere! LOLLERS lrn 2 program!!) isn't.

So, yeah, if you could explain precisely what a DSL is, maybe I could understand it. (As a programmer, I write and use APIs all day, and they look pretty dang similar, except that I don't use string-eval.)

I think you had a brilliant chance to talk about maintainability, the use of ubiquitous language, domain driven design, simplicity, and usability of interface, but instead you grabbed for the new bright and shiny. (Perhaps I'm just a dinosaur, but Aristotle isn't convinced either, and he's smart.)


DSLs: Language or Dialect

iburrell on 2007-08-17T04:19:16

In some ways, this debate is like the one over the difference between languages and dialects with human languages. I would say that something that determines a domain-specific language vs a dialest is having a separate existence. Is the DSL defined separately from the parent language? Could it be parsed by another parser without the complete interpreter for the parent language? Or is just a convention and API to represent the domain?

A good example is JSON. JSON started out as JavaScript, but was specifically chosen as a limited subset. Simple and useful enough that people have written parsers in other language. People are even working on a JavaScript parser so they don't need to write use eval().

Re:DSLs: Language or Dialect

Aristotle on 2007-08-17T11:56:55

That’s an amalgamation of the point made by Piers Cawley and some by Ovid.

I think this is a discussion with lots of distinctions without a difference. It’s like we’re trying to define what pornography is.

Re:DSLs: Language or Dialect

chromatic on 2007-08-17T21:59:53

Or is just a convention and API to represent the domain?

Obviously it can't be that, or you could write DSLs in Perl, which Cosine suggested is impossible.

My main objection is that the whole mad-foaming rush to drool over three little letters so overshadows much more interesting discussions, such as:

  • To what degree do general purpose programming language design issues affect expressibility?
  • To what degree does the expressibility of your programming language affect the robustness and ease of producing useful software?
  • How can the dialect of the problem domain affect affect the maintainability and correctness of the software?
  • Shouldn't everyone be able to build a compiler, and shouldn't the resulting language be able to take advantage of well-written libraries written in other languages or dialects?

Sadly, instead we have what appears to be a small army of programming novices just parroting the words of some of the least-thoughtful advocates of languages and platforms I've ever encountered. Trying to get them to commit to a definition of exactly precisely what in specific they're actually talking about is... well, an ordeal.

I'd feel a little intellectual thrill if just one of these "WOWEE DSLS!" people could have a serious conversation about either "Don't people who use this DSL have to learn the syntax and semantics of the host language anyway?" or "You have access to the full syntax and semantics of the host language as an escape hatch; why not take advantage of that?" So far, no luck, and in those kinds of situations I tend to point out absurdity with absurdity.

Re:DSLs: Language or Dialect

Alias on 2007-08-19T17:45:04

> "You have access to the full syntax and semantics of the
> host language as an escape hatch; why not take advantage of that?"

One of the nicer things about Module::Install (lets ignore the whole fundament disagreement over the concept for a moment) is the nice little DSL (\o/ yay \o/) it uses, and the fact you CAN mix the regular language in with it.

use inc::Module::Install;

name 'foo';
all_from 'lib/foo.pm';
requires 'Bar' => 1.01;
build_requires 'Test::More' => 0.42;

if ( $ENV{AUTOMATED_TESTING} ) {
        build_requires 'Test::Pod';
}

WriteAll;


Does this meet the criteria for a DSL? :)

Re:DSLs: Language or Dialect

chromatic on 2007-08-19T23:54:19

Does this meet the criteria for a DSL?

$ perl -MO=Deparse is_it_a_dsl.pl
use inc::Module::Install;
name('foo');
all_from('lib/foo.pm');
requires('Bar', 1.01);
build_requires('Test::More', 0.42);
if ($ENV{'AUTOMATED_TESTING'}) {
    build_requires('Test::Pod');
}
WriteAll();
- syntax OK

It's as much a DSL as any other API where you leave off parentheses. In my book, that's a "no".

Re:DSLs: Language or Dialect

Aristotle on 2007-08-20T00:19:57

Almost: it’s not Ruby.

Re:DSLs: Language or Dialect

jjore on 2007-09-03T06:30:18

To the extend that omitting all the parentheses and pointy bits makes it just an obfuscated form of perl, no.

Re:DSLs: Language or Dialect

Aristotle on 2007-09-03T07:05:58

Obfuscated…?

Re:DSLs: Language or Dialect

jjore on 2007-09-03T07:41:57

Well sure. Anytime you go taking parentheses and pointy bits off function and method calls you introduce ambiguity about what the invocant is, what the method or function name is and what its parameters are.