in reply to Top 11 (GOOD) reasons not to use someone else's Modules
And here are 11 sometimes rude responses.
- LEARNING § this entirely valid point is only entirely valid if the only point is learning; i.e., if this an excuse to do code you expect to be production worthy or vendible, this sloth has a girlfriend, your point is invalid.
- PERFECTION § You've confused perfectionism with narcissism. Perfectionist seek the best possible answer, not the best answer they are capable of delivering.
- PURPOSE § You don't parse output of things you want to change, you write patches.
- APPEARANCE § this is an ideal point for the Kardashians, and businesses bent on irrelevancy.
- PORTABILITY § the difference between a file and a folder is insignificant; i.e., everything in one folder is just as "portable" as everything in one file and a bazillion times less confusing for any significant amount of well-written code. Badly written code does indeed tend to be easier to navigate in a single file though.
- CPAN ACCESS § see PORTABILITY and a hundred threads on PerlMonks regarding this topic.
- COMPILING § see PORTABILITY + pre-compile it on the same system/hardware for binary compatibility.
- COMPLEXITY § The instructions for getting non-root local::lib and cpanm are trivial and are basically fix and forget.
- SIZE § Without benchmarking, this is bias. Without analyzing which modules vs what code, it might also be upside-down.
- LICENSING § Legal issues are outside the scope of dev advice, so, you win this round, Greater Bandicoot!
- JOB § Cheating? Installing Moose breaks neither the laws of God nor *man. The laws of tye and BrowserUK however...
Off the soapbox and back to making work less unpleasant for the devs who have to maintain the code I write.
In Section
Meditations