Please don't do this -- see ruby for the reason why. Say I want to do X in Perl. I head over to search.cpan and look for the word X, and odds are good that I'll turn up the relevant modules, because "X" appears in their names (with POE, PDL, and Maypole being notable, and annoying, exceptions). Now say I want to do X in ruby. Odds are good that ruby's X-module won't have "X" in its name, but will be named something obscure and "clever", so should I be looking for "Floozy"? "Bogey"? "Droopy"? How many of you have discovered a standard Unix command to do something after having written an inferior replacement yourself, because you never would have guessed its cryptic name? CPAN works because I can find a module based on what it does, without some other resource mapping functions to names. | [reply] |
I'd totally agree... if the module's function was, as a Unix command is, small and tightly contained. If I'm looking for a module to give me some FTP functions, you bet I'd want the module to reflect that in the title.
On the other hand, something that gets to be a large framework, that almost by definition is a collection of smaller items put together in a useful way to allow you to easily accomplish some bigger task, very often could be served well by giving it a name. By your rationale, is "Apache" a terrible name for a webserver? Would we be any better off were it called "Open Source HTTP Server"??
Anyway, not sure we really disagree -- perhaps you missed the context in which I made my initial remark (to the idea that the OP's module was becoming a framework rather than a small utility).
| [reply] |
Point taken, mostly... However, I'd say that even something so nebulous as a framework should have some concise description. If it doesn't, it probably should be either broken up or put out of its misery. The name "Apache" is necessary because an "httpd" is a common, well-established chunk of software with many implementations. There's no particular feature that distinguishes Apache within its niche; while it may be better than IIS, there's no concise description of how. Therefore Apache has to be distinguished based on a label or brand.
Given Apache's brand recognition, it's not such a bad name, but if it were distributed through CPAN, it should be called "HTTP::Apache" or "HTTP::Server::Apache" or something. In some sense, CPAN's naming works because it puts function before brand, making it easy to find software to solve particular problems affecting small numbers of people, and to distribute solutions to such idiosyncratic problems. If CPAN becomes more and more about reinventing subtly-different wheels, then tags or "brands" will be required, but for it to continue to work, these should always be subordinate to the functional labels.
Personally, I'd much rather see people working to improve existing modules and solve new problems than write endless config- and argument-parsing modules, web application frameworks, or what have you. I understand the appeal, but at some point your alternate approach won't be different, better, or cleaner, but merely "other". People will choose your module for the same superficial, brand-identification reasons they choose Crest over Colgate. Your module's needing a vanity tag suggests (but doesn't necessarily entail) that you may be in this situation.
/s
PS: Looking for something to adopt? Identify the 3-4 ordered collection (heap) modules on CPAN, choose the one that sucks least, and give it a beautiful, natural tied array interface and a screaming XS backend.
| [reply] |
