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.
  • by systems (5732) on 2008.09.10 16:07 (#64830) Journal
    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 like BI, Data Mining or Transaction Management Systems. Whatever definition you will find, it will be far from the actual product, that most developers will create, and most business users will use.

    DSL, is kinda, one of these terms, that people tend to over complicate, and this doesn't help outsiders (Business people), or insiders (IT people) who are new to the concept.

    I do like Martin's DSL categories, they are simple, clear, straightfoward and useful.

    I will paraphrase what you said he said to clarify why I think they are useful.

    I'd say you have two kind of Perl DSL. Internal, and External.

    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

    External DSL, is a new language, specially crafted to solve a specific type of problems. Like regular expression.

    And to elaborate furthur, and to explain why DSL is good, not just for Business people, and that it is not just about syntax. DSL is about providing delcative solutions vs. procedural ones.

    Using an Internal or External DSL, should shield you from reverting to tradional program languages constructs like Loops and Conditionl branches. You should be able to only use the DSL code to solve the Domain Issue by coding what you want done and without having to specify step or write algorithms using loops or conditional branches and explaining how the problem should be solved.

    Moose does exactly this, I declare classes using the Moose provided syntax, I don't use previous, older or traditional Perl OOP idiom. And this makes Moose code shorter, clearer, cleaner and more intuitive, I don't read algorithims when I read Moose code (I mean the code used to create classes and types), which is specifically what in my opinion make Moose worth using.

    One thing I dont know, is, if Moose is Internal or External DSL, and according to most of the Moose tutorial I read, I should not care.

    Moose is probably a hybrid DSL, as it introduce new Keywords (or so they say) and other than that its Perl code.

    I ultimatly find the DSL categories introduces by Martin useful, they allow peole to answer simple and common asked questions. Like is this syntax Perl Code or an External DSL. The differentiation can help developer at different better read, learn and teach the code. Better communicate using smart, clear well defined term that may have the effect or reducing the complexity of a complex concept.

    I hope i was clear, and not to long, and that my message got through, and was perceived as smart.

    For example how do you feel about the follwing statement: " ... technically, regex are hybrid DSL in Perl, but they lean more on to the external pole of DSls. You can write a Perl Regex without having to know most of Perl. The regex part of the program that is. Which means, it is easier to delegate Regex writing to outsiders! Because Regex is more external"
    • 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