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)

Wednesday September 10, 2008
01:33 AM

You Can't Get There From One of These Heres

[ #37397 ]

An internal DSL is just a particular idiom of writing code in the host language. So a Ruby internal DSL is Ruby code, just written in particular style which gives a more language-like feel. As such they are often called Fluent Interfaces or Embedded DSLs. An external DSL is a completely separate language that is parsed into data that the host language can understand.

...

I see DSLs as having two main benefits.... The most interesting benefit, however, is that a well designed DSL can be understandable by business people, allowing them to directly comprehend the code that implements their business rules.

Martin Fowler, DSL Q and A

Like minicomputers of old, I can program my microwave by entering programs on its keypad. Unlike minicomputers of old, those programs are not Turing Complete. My microwave has a domain specific language which allows me to control the amount of microwaves it emits and the length of time it emits those microwaves. There are some complications; you have to get the order of operations right (first time, then power), and the syntax for entering times is slightly complex (two-digit values are in base 10, while three digit values are in base 60). Yet it's also simple enough that non-programmers can use the device regularly without realizing that they're writing simple programs.

Now imagine that they had to program my microwave by using a fluent interface written in a general purpose host language. Suddenly the two-digit/three-digit assumption for base switching is inappropriate; there may or may not be a time context in which to interpret numbers, for one thing, and a leading zero may imply the use of octal as it does in many C-like languages.

While there may be an easy and obvious way to reheat chicken parmesan with this fluent interface, there may be multiple effective ways to count the time, and the syntax and semantics of seemingly equivalent programs may differ in efficacy, efficiency, and side effects. Of course, it may be easier to reheat pizza, where a minute at half power and thirty seconds on full power is most effective -- you could make a separate function to reheat three slices. (I wish I could.)

You can get the same effect both ways. The important consideration is of benefits and drawbacks.

Martin is completely right that using the language of the domain effectively can help communicate domain concepts clearly between business people and technical people, but I believe he's wrong that a so-called "internal DSL" is effective at doing so.

Why?

Because (as people who dislike Perl oft expound) understanding a piece of code requires you to understand the operations and idioms used in the code.

To understand a SQL query containing a join (a declarative domain specific language for managing relational data), you need to understand (some portion of) the relational model. You don't have to understand the indexing algorithm used to select matching rows or the storage format of rows in relations in a persistent medium.

To understand the related procedural code to perform the same query without using SQL, you have to understand the indexing algorithm and the storage format -- or at least how to use API calls to perform those operations. The possible implementation decisions and semantics are much broader.

If Moose had a declarative, compile-time language for declaring classes and attributes, you could compare it to the existing "language", which relies on Perl parsing rules and quoting rules and may rely on order of compilation rules in some contexts.

While I agree that a reasonably skilled participant in a domain may be able to get a rough impression of the business logic expressed in a so-called "internal DSL" -- certainly enough that she may be able to debug blatant logic errors -- the knowledge of the host language's semantics is necessary for a direct comprehension of the implications embedded in that pidgin. You still have an API Town mailing address, no matter how much you want to pretend you live in the wonderful Land of I Can Writed a DSL (unless you want to claim that we're all born with an intrinsic understanding of Ruby's variable/method scoping/shadowing rules and the difference between a Symbol and a String, like some sort of Jungean glossalaia).

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.
  • To start I am not a fan of the modeling gang like Martin Fowler and his buddies of the agile manifesto, I believe they ruined the topic (software modeling) for generations to come, they took something smart and turn it into something dumb and silly, and not smart at all!

    But I have to say, every now and them being the veterans that they are, something smart comes out of them.

    I believe that the IT literature, writing or whatever suffer from ill defined definitions.

    For example, surf the net for definit
  • To start I am not a fan of the modeling gang: Martin Fowler and his buddies of the agile manifesto, I believe they ruined the topic (software modeling) for generations to come. They took something smart and turn it into something dumb and silly (and not smart at all)!

    But I have to say, every now and them being the veterans that they are, something smart comes out.

    I believe that the IT literature and writings suffer from ill defined definitions.

    For example, surf the net for a definition of things lik
    • Internal DSL, is Perl Code or a library, with an interface that clear, simple and intuitive, to the extent that people with no Perl training (or very little), can correctly guess its meaning....

      That's like suggesting that I can understand technical jargon in Danish by guessing at apparent cognates. I might be right once in a while, but that's luck. The fact of its jargonness and my familiarity with that jargon doesn't make it suddenly not Danish, such that my unfamiliarity with Danish ceases to be a pro

  • About a decade ago I learned the trick of writing a data-driven Perl program. The data comes out of a Perl data structure in a configuration file.

    Despite the fact that the configuration is pure Perl and could potentially do anything you can do in Perl, in practice I've been able to show it directly to a domain expert with no knowledge of Perl, they read it, we can talk, and they generally don't have trouble editing it.

    Going in a different direction, both Class::DBIx and Rose::DB come with pure Perl query i

    • All they did was take a simple dialect of Lisp and add a bunch of domain specific functions to it that were specific to the product.

      My goodness, if other programmers realized that this were possible, we'd have a revolution on our hands! It may be hubris for me to presume that I could potentially name it, but how about the term "structured programming"?

      I know... I kid, mostly because even a good macro assembler offers that kind of abstraction.

      Despite the fact that the configuration is pure Perl and could

  • So now at least I finally have a term (albeit a terrible one) for what Module::Install gives you.

    I just wish that "Internal DSL for Module Configuration" didn't end up having the same level of weasel as "Democratic Republic of North Korea"