Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Tuesday March 11, 2008
05:31 PM

PragDave Nearly Gets Internal DSLs Right

[ #35885 ]

... let's look at it from a DSL point of view. What is the domain? I'm thinking it is the specification of the correct behavior of programs. And who are the domain experts? That's a trickier question to answer. In an ideal world, it would be the business users. But, the reality is that if the business users had the time, patience, an inclination to write things at this level, they wouldn't need programmers. Don't kid yourselves—writing these specs is programming, and the domain experts are programmers.

Pragmatic Dave Thomas, The 'Language' in Domain-Specific Language Doesn't Mean English (or French, or Japanese, or ...)

So very close.

The reason the so-called DSLs that Dave mentions are inaccessible to non-programmers is that they're merely Ruby APIs with poor encapsulation. People who do not know how to program Ruby code will have a difficult time reading and writing them. This is not exactly a feature, if you want business experts reviewing your executable specifications.

I'm sure they love looking at RSpec output and saying "Right there, it says the Wooble does not have a built-in Flimflam, that's the problem right there! Just fix that!" By the time RSpec spits out that helpful notice, it's already detected the problem. Useless, except that making RSpec actually useful to business experts requires something more than slapping the colon in front of random Ruby identifiers.

(ObContraDanielBerger: slapping the fat comma operator between indirect object invocations in Perl produces code that's just as bad and just as much not a DSL. The Perl community doesn't have this particular fetish to the same degree as the Ruby community though. Happy?)

Ever since programmers at large stopped having to cram their meaningful identifiers into eight characters (a feature planned for GHC 12.2, I believe), we've been able to subsume the language of the problem domain into our APIs.

Dave continues:

When you're writing logic like this, with exception handling, command sequencing, and (in more advanced examples) conditionals and loops, then what you're doing is programming.

This, more than anything, I think is the real dividing point between a DSL and an API. Here's my postulate for the day: a real DSL (make, procmail, SQL, regular expressions, FIT) is purely declarative.

I realize that Prolog might be a DSL under that definition, as might class declaration in Ruby (and ActiveRecord), but I can live with this as a first-order differentiator.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • For a great example of a DSL that doesn't follow your "only declarative" rule is VoiceXML, which is absolutely a DSL.

    If contains a sort of odd mix of declarative structures, mixed in with bits and pieces of logic ...

    While I personally HATE this whole "XML as code" idea, in VoiceXML it works wonderfully.

    Go read up on it, any study of DSLs is incomplete in my opinion without understanding VoiceXML.
    • For a great example of a DSL that doesn't follow your "only declarative" rule is VoiceXML, which is absolutely a DSL.

      Good point.

      "Purely declarative" is a red herring. The question is whether the language is general purpose or domain specific. Ruby (and Ruby APIs) are general purpose. That's sort of the point of a general purpose language: to allow you to write domain specific APIs. (Thank The DHH that his followers delivered us from such mundanity.)

      In the same way, XML exists as a tool to descri

  • I'm not sure that procmail's entirely declarative either, given that you can embed shell scripts within it (but then, I guess, those bits are no longer domain specific in quite the same way - as far as procmail is concerned they're data...)

    I still maintain that there are real DSLs that can be written and embedded within a general purpose language (regular expressions being the canonical example). Damian Conway's List::Maker is an example that uses a parser, but something like Object::Declare is, I'd argue,
    • I agree that you can use a flexible host language to write things that have a different feel from just a plain API, and that one might reasonably call those DSLs, and that making too fine a point about distinguishing the two isn’t a very productive use of time. But there’s a lot of hot air from parts of the Ruby camp about how that language has the DSL market cornered, without any objective criteria forthcoming about what other languages lack in that department. And I agree with chromatic that a

      • Well, yes. But idiots will be idiots and there's not a great deal we can do about it. I just worry for chromatic's blood pressure and wonder if he's indulging in pig wrestling.
        • I just worry for chromatic's blood pressure....

          It's actually on the healthy side of low.

          ... and wonder if he's indulging in pig wrestling.

          What's the Internet for if not pig wrestling over technical minutiae and fanfic?

    • All that said, I still don't really see the value of making fine distinctions about what is and isn't a DSL.

      The concerns of language design and the concerns of API design overlap, but not fully. Syntax considerations matter far more in language design. This is why certain Rails APIs have stupid little do-nothing-but-forward-messages methods such as #a and #the.

      I worry that the focus on creating these APIs produces unmaintainable messes of code. There's little chance that a business user who doesn't

      • My thinking is that people who are going to produce unmaintainable messes are going to produce unmaintainable messes no matter what road they take. This year it's internal DSLs, last year it was patterns, next week it might be computed gotos. Let's just be grateful that they've not discovered how callcc works.

        Then again, I'm not sure there's a better way of learning how not to produce an unmaintainable mess than to make (at least) one and the reflect on how you messed up.

        • I'm not sure there's a better way of learning how not to produce an unmaintainable mess than to make (at least) one and the reflect on how you messed up.

          The nice thing about weblogs is that you can mislead a lot of people before you learn your lesson. Then again, several parts of the Perl core documentation are outright wrong in terms of good style....

          • The nice thing about weblogs is that you can mislead a lot of people before you learn your lesson.


            Hey, if that gets 'em to their own personal lesson faster, where's the harm? Okay, so they might end up thinking you're an idiot for misleading them, but so what? They're probably right.