Re: TMTOWTDI... and most of them are wrong

[revdiablo]

Nice post, if for nothing else than making me think about the topic at hand. I think there's a lot of intuitive appeal to the logic that scary, interesting, and clever code is a detriment to code reuse. But I also think CPAN's success is a testament to that idea being a bit off base.

I won't pretend that I can explain why, but people have been posting idiomatic, obfuscatory, excessively clever, and even downright bad code to CPAN for a long time; yet it still seems to work out pretty well. People contribute. People reuse. The net effect seems to be positive, and a lot of good stuff emerges from the chaos.

[Zaxo]

I agree, and here's why I do.

CPAN provides lots of ways to Test, and CPAN harnesses testing as part of the build process. The effect is that you don't have to trust people to get it right every single time.

By testing for results you must have rather than having hoops programmers must jump through, Perl and CPAN let all sorts of odd ideas, grand schemes, quirks, mathematical verities, lunatic notions, sacred cows, juicy hamburgers, oracular goings-on, lies, damned lies, divine inspirations, hallucinations, high science, low comedy, and too many other squibs to list, coexist. The cream rises to the top.

Trust is fine, but test and experiment and imagination are finer.

[DrHyde]

Yes, we have tests. Yes, you can choose not to use modules which have no tests. Unfortunately, there are modules (and I'm guilty of creating some) which have only a minimal "it compiles" test. There are others which are damnably hard, if not impossible, to write tests for, and so you can't really be sure that they have adequate tests even if they have lots of them. And then there are modules which have *thousands* of tests, and you know damned well that they aren't all needed and so get suspicious about the quality of the tests for yet another reason.

[revdiablo]

I'm not sure if this is the same point that Zaxo was making, but the test suites of other modules are only part of the picture. The other part of the picture is your test suite. A module you're using may have a terrible, non-functional test suite with very low coverage. That doesn't matter as much, though, as long as your own tests cover the things that matter to your program.

Maybe this doesn't apply to quick scripts written directly against the CPAN modules in question. But any time I'm doing a project of any reasonable amount of complexity, I tend to write most of the code in application-specific modules. This is where I do my testing, and this is where I can ensure my application is returning sane results. If a CPAN module I'm using from within this code is doing something strange, I will tend to find out about it.