comment on

Class::MethodMaker is symptomatic of a problem that is causing me more and more frustration. Bricolage, as many know, is rather difficult to install. A huge part of the problem isn't Bricolage itself (once the dependencies are in place Bricolage is a piece of cake to install), it's the twisty little maze of annoying dependencies which are the bulk of the problem. Some dependencies don't list all of their dependencies. Some fail their tests but run just fine. Some fail their tests but those failures are portions of the software we don't use. What's a programmer to do?

Personally, I've sent plenty of bug reports to authors. Sometimes they fix them. Sometimes they ignore them. I've sent plenty of patches to authors. Sometimes they use them. Sometimes they ignore them. Sometimes I've just sent a damned tarball with everything working only to receive no response. In fact, there's one piece of software I use regularly which I've patched locally because I've been waiting over a year for the author to keep his promise to incorporate my patch (I'm not naming the code but I'm pretty annoyed by this).

What do these various modules have in common? They're usually large "wunderkind" modules which do everything you could ever want and your dishes too. Unfortunately, they have a nasty habit of breaking those dishes. Class::MethodMaker is a great module and I've used it quite a bit in the past, but it's been seriously failing its installs for over a year and these don't appear to be the typical failures related to the CPANPLUS bugs we've all been plagued with lately. This is a problem I keep encountering and it's frustrating when I run into huge modules which keep failing and I only need a small fraction of its functionality.

So I suppose I can look at Class::MethodMaker's XS code and regular code and try to see what's going on but frankly, it's very confusing code (just take a look at Build.PL and Makefile.PL). With Class::Trait, I sent enough patches and suggestions for complicated code because I needed it (that was before stvn gave it to me). With so many other modules, I face the agonizing task of maybe having a bug fixed, maybe having a patch accepted, maybe having some response from the author when, for the most part, I don't need that code.

There's nothing wrong with wanting small, lightweight modules that do exactly what I need and do it well. There's absolutely nothing wrong with trying to build big modules that do everything an end user might need (I've written some of them), but there's also nothing wrong with deliberately trying to get small, easy to install modules that just friggin' work. The problem is, when we release large software packages with many dependencies, relying on other large software packages with many dependencies means that more things are likely to break and my software is less likely to be useful.

So when perrin reasonably suggests that I reuse existing code, I feel trapped between Scylla and Charibdis. If I follow his suggestion, I'm going to spend more time on something which may or may not work only to incorporate code which makes our products harder for others to install and use. Or, if I create a small, powerful alternative which is much less likely to break, I can silently incorporate it in our code and not get a chance to share it or I can put it on the CPAN and have people get upset with me reinventing the wheel.

This is why Joel Spolky's defence of "Not Invented Here" syndrome is more and more appealing to me. I really don't know what else to do. Should I not "pollute" the CPAN with easy to use modules which might duplicate functionality? There are definitely pros and cons to this approach, but I'm beginning to think that if I "reinvent" any wheels, maybe just not releasing them is the way to go. That sounds selfish, but I'm also concerned about CPAN pollution. It's often difficult to find what we need and if everyone releases every module they've ever written, it's going to make a current bad problem even worse. I really don't know the best solution here.

Cheers,
Ovid

New address of my CGI Course.

In reply to Can I please have *simple* modules? by Ovid

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


Welcome to the Monastery
	PerlMonks