good chemistry is complicated,
and a little bit messy -LW
Re: Top 11 (GOOD) reasons not to use someone else's Modulesby Tanktalus (Canon)
|on Apr 23, 2012 at 18:12 UTC||Need Help??|
1. I get some pay for education. Not that much.
2. I want perfect code, too. That's why I rely on others who have spent more time on the problem than I have available to provide one for me.
3. I've noticed that at least 50% of the time where my goals and existing modules diverge, it's because my design is wrong, not the modules. Once I realised that, I learned a lot more. (See #1.)
4. I prefer to correct the appearance than to work around it. (See #2. Misjudgement is imperfect.)
5. Module::Install seems to work for me.
6. If you can get to the system, you can use scp to the system. Also, I prefer checking the desired modules' tarballs to my version control system, which then gets me through all the firewalls. At least as well as any of my other code.
7. Our target systems don't have compilers, either. We build on a build machine, and deploy on test machines.
8. I had this one just last week. Someone decried how hard it was to monitor a process with an async process. But because I already had AnyEvent installed, I whipped together a proof of concept of how easy it was in about 20 minutes and about 44 lines of code (with plenty of whitespace). I had AnyEvent installed to manage parallel ssh calls, but it made this one trivial. Many modules have multiple uses.
9. Ok, you got me here. My target boxes have 16 CPUs and 30+GB of RAM.
10. Don't grab GPL-only modules. Most modules on CPAN are dual-licensed: GPL or Artistic v1. Some are only Artistic v2. And I've not encountered any that are GPL-only. And I'm going through the legal review right now.
11. You're paid to write code? Where do you work? I'm paid to deliver solutions. Often that involves code. Often it doesn't.