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

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.
  • 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, a full on DSL that works by finessing the perl parser and its runtime structure without having to introduce a new parser.

    Personally, I think RSpec's specify/describe stuff for specifying tests is as near to being a DSL as makes no difference, but the .should == "foo" stuff is just a clever set of classes and methods. But, that's a mighty big 'just'.

    All that said, I still don't really see the value of making fine distinctions about what is and isn't a DSL. The only question that needs to be asked is "Does it work?". I simply couldn't care less about what you want to call it (or even, in the case of RSpec, what claims you make about it).

    I take the view that programming is language design. The second you take a bunch of code, and give it a name so you can call it later, you're designing a language (admittedly, it's one that looks _very_ like the language you're implementing it in). The languages I like are those that blur the boundaries between the language and its libraries.

    Hmm... comment in danger of turning into a blog post... I'll stop here.
    • 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.