|Keep It Simple, Stupid|
"Perl Design Patterns"by tjh (Curate)
|on Jun 14, 2003 at 15:29 UTC||Need Help??|
Recently an article appeared on perl.com titled "Perl Design Patterns".
Not having the CS background many monks have, such discussions help me better understand issues surrounding design, and often, these discussions help me understand that sometimes when I thought I didn't need to worry over design issues - that I was kidding myself.
In the past, I've enjoyed PM threads such as these on the same subject:
And those have led me to:
These discussions have helped me come to understand Perl better, and in some ways, have helped me come to grips with new Perl 6 design issues or decisions I often don't fully understand.
In the perl.com article, the section titled "If a pattern is really valuable, then it should be part of the core language", contained this phrase, "Perl succeeds largely by excellent use of the principle of promotion. Essential patterns are integrated into the core of the language. Useful things are implemented in modules. Useless things are usually missing."
And frankly, that phrase tweaked me a different way in maybe understanding some differences between Perl, and some other languages, as well as getting a little insight into language design itself.
However, not all that glitters is gold, so what are your thoughts on this? Are the author's thoughts on Perl and design patterns more right than wrong?
Why wouldn't a language move "essential patterns" into the language's core? Why haven't other languages evolved a CPAN equivalent, which, to my naive eyes, has simplified and modularized essential, useful and/or interesting elements, saving me from fatal design pattern decisions?
And, as an aside, I'll bet the decisions and debate around what consitutes an "essential pattern" can get quite heated. Also, one wonders if this "essential pattern in the core" issue is any kind of force in Perl 6 development. If so, for instance, is memoization an essential pattern, per se?