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
--Larry Wall in <199911192358.PAA24109@kiev.wall.org>
Did I say I expect Perl to do the right thing? :-)
--Larry Wall in <199911200217.SAA24898@kiev.wall.org>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
I disagree! (Score:1)
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: "
Reply to This
Re: (Score:1)
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