|No such thing as a small change|
Re: CPAN module fior common idioms?by halley (Prior)
|on Jul 23, 2004 at 14:03 UTC||Need Help??|
While the snippet you showed in your example is easily packageable, many idioms are not. Idioms share a lot in common with patterns, which are essentially mental blueprints for common approaches to recurring problems. However, many idioms and patterns also share the unfortunate trait of forming a framework for other tasks, instead of forming a task in its own right.
The seminal work in recognizing and applying patterns is Design Patterns, also known as the "Gang of Four" book referring to its four authors: Gamma, E., R. Helm, R. Johnson, and J. Vlissides.
Many apprentice programmers pick up the Gang of Four and are a bit overwhelmed with the concepts introduced at first, but generally start to recognize the appropriate patterns that already exist in application code. This is an important skill to acquire: recognizing idiomatic development in existing projects.
Many journeyman programmers pick up the Gang of Four and try to write a library of code that implements the basic interfaces of each pattern. They quickly get out of their depth, trying to implement a flexible and approachable system which makes writing applications easy, yet doesn't hinder the application from doing obvious special work on top of the basic pattern.
In my observations, so-called master programmers generally don't rely on idiom libraries or pattern classes. They rely on data structures libraries, surely, but idiom is meant to be flexible in ways that libraries can rarely deliver. For example, how do you write a Perl5 library to handle the Schwartzian Transform? Every programmer cuts and pastes this approach, or types from memory, to speed up their critical and complex sorts. But writing a library to handle the obvious alterations would be heavier than the perceived value of having such a library.
Instead, where appropriate, melt the powerful idioms into the language itself: Java absorbs assert(), and Perl 6's sort will do internal optimizations akin to the Schwartzian Transform.
There will always be inappropriate or inconveniently persistent idioms that resist packaging: unique() and slurp() come to mind. Should they be a library? Or should they be one-liners that you can type from memory?
The reason they resist packaging: how do you handle the special cases, the empty lists, the degenerate worst-case work, the nonstandard separators, the already-sorted, the deep data structures? Each time you type these idioms, these issues raise their heads and you adapt your idiomatic solutions to cover them. It's my expectation that those special cases are exactly why they haven't been absorbed into the language already.