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,
    • 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 know Ruby is going to write code (or read it and understand all of its nuances correctly). Ruby syntax -- especially parser corner cases tied to particular implementations -- keeps leaking through.

      As well, that syntax and the contortions required to make something look like English doesn't help Ruby programmers either. Ruby has a fairly nice syntax with blocks and methods (barring the proc/block and the end-of-argument-list weirdnesses). Why uglify that syntax to create an API that reads like instructions for setting up a cheap imported bookcase?

      The languages I like are those that blur the boundaries between the language and its libraries.

      In my opinion, APIs that are neither good examples of programming language nor the language of the domain do not serve this goal.

      • 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.