I understand all these (valid) reasons, and release modules when the corresponding concepts can be used as modules. But there are cases that don't fit in the box, and neither should, and I'm talking exactly about these cases. Not to be empty-worded, here's a concrete example (excuse me for a shameless plug of my own script):
http://search.cpan.org/~karasik/sqlpp-0.05/bin/sqlpp
This is a simple cpp-like preprocessor with injections of perl syntax. It can be done in a thousand different ways, and if I indeed generalize it as a module, I'll need to justify the existence of it, especially when there's Text::Template and what not. The point is that there's not much to generalize, really. Who needs yet another CPP.pm with fixed syntax?
Another example, to show when indeed creating a module is possible, but not necessarily needed:
http://search.cpan.org/~karasik/Subtitles-0.09/subs
this is the script that comes with a module, and even though the concept is generalizable, I seriously doubt that anyone would use this module to write their own subtitle handling program. Suppose I'm wrong, for the sake of argument, but why then we have this?
http://search.cpan.org/~miyagawa/Video-Subtitle-SRT-0.01/lib/Video/Subtitle/SRT.pm
when the subtitle module I wrote is already there? I'm not jealous in any way, let the thousand flowers bloom etc.
but I don't want to create a different module when all I want is a different program. I think that this is exactly the case when entities should not be multiplied beyond necessity. I don't know who is "we" who "want my code", thanks for that :) but I neither think that
you should generalize what people want from CPAN.
| 