http://qs321.pair.com?node_id=966634


in reply to Top 11 (GOOD) reasons not to use someone else's Modules

And here are 11 sometimes rude responses.

  1. 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.
  2. PERFECTION § You've confused perfectionism with narcissism. Perfectionist seek the best possible answer, not the best answer they are capable of delivering.
  3. PURPOSE § You don't parse output of things you want to change, you write patches.
  4. APPEARANCE § this is an ideal point for the Kardashians, and businesses bent on irrelevancy.
  5. 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.
  6. CPAN ACCESS § see PORTABILITY and a hundred threads on PerlMonks regarding this topic.
  7. COMPILING § see PORTABILITY + pre-compile it on the same system/hardware for binary compatibility.
  8. COMPLEXITY § The instructions for getting non-root local::lib and cpanm are trivial and are basically fix and forget.
  9. SIZE § Without benchmarking, this is bias. Without analyzing which modules vs what code, it might also be upside-down.
  10. LICENSING § Legal issues are outside the scope of dev advice, so, you win this round, Greater Bandicoot!
  11. 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.