hardburn tosses metaperl down a Turing Tarpit
"General Purpose" does not mean it's good for everything; only that it's possible. BrainF*ck is technically a General Purpose language (in the sense of being Turing complete), but do you really want to write everything in BF?
What do you do when your main language doesn't make it easy to solve your problem? (This will happen in any language, even one as large as Perl). You have two options:
As far as your maintance programmer is concerned, the two actually don't make a big difference. They either have to learn a new API, or a new language. If the problem is small, then either solution should be small. If the problem is large, then either solution should also be large. But I bet one of the above solutions will be significantly easier than the other, and a responsible programmer should learn to create both and apply them as necessary.
Forgot to add a feature that the end user needs? In either of the above cases, they still need to come back to you to add it.
No, we don't need another templating language (or API, for that matter). But what does HTML::Seamstress work on? HTML, which is a kind of mini-language. So you're not getting away from mini-languages by using that module.
What I can't stand is the attitude that Perl is the One True Way. TIMTOWTDI does not mean "there is more than one way, but that way is done in Perl". There are some really interesting ideas out there that Perl doesn't use (like Hindey-Milner type inferencing), and would have to be changed into an entirely new language to support.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
In reply to Re: MINI LANGUAGES SUCK
by hardburn
in thread the disadvantages of mini-languages
by metaperl
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |