Absolutely true, and mind-numbingly aggravating. I hear "only use core" all the time, or maybe "only use what you can find via yum in the official repositories for this antiquated CentOS version we're using." It's like telling me to only run my car only with what was in it when I bought it, or maybe using the resources available at the dinky little gas station around the corner from my apartment.
It takes little research to discover what modules are available and actively maintained. Unfortunately, that's not enough to satisfy a corporate policy that fears the outside world. Pardon me, I need to go find a brick wall to smash my head against for a few minutes.
Oh, that original could would be at least a little cleaner if it just split each line into a key/value pair and stored the results in a config hash. It wouldn't necessarily solve the problem of the missing value, but it would be easier to debug by reducing lines of code.
Now about that brick wall ...
| [reply] |
It may not always be possible but that is not the case here. It is bad code, and the programmer needs to fix it. The easiest way for them would be for them to use a module. It would solve two issues, it makes them more flexible to new solutions, and there is a good chance that it will work better than anything that is home grown.
It is easy to say its corporate politics that prevents me from doing 'blah' and continue doing what you are doing.
I find that it leads to people who think they know more than they do, writing more code than they should and introducing bugs because of things they have not thought of before... And more than likely, they just did not ask!
| [reply] |
I live in a strict political climate, myself. My only point here was not to discourage the use of modules but not to chastise folks who need to roll their own as being ridiculous for trying. Half the time I see veteran SOPW'ers on here saying, "Please do not tell me to use Modules," but I do not think that takes away from the legitimacy of the question or poster.
| [reply] |
| [reply] |
No, you can't, Grandfather. For example, code contamination rules.
| [reply] |
That's basically covered under scenario #3, "Manager support". Seriously. Start by talking to your manager about the situation. There are two types of "contamination" that I can imagine your employer being worried about: copying of unauthorised code, and licensing issues. The first one is pretty easy to manage. Point out that you will not be copying unauthorised code. You won't be taking the CPAN code and putting it into your code. You'll just install it, and use it, just as you would Boost's C++ library, your C compiler's C library (such as MSVC*.DLL), or any module that comes with Perl.
The licensing issue is a bit more painful, but ask if your corporate lawyer wouldn't mind looking at the license that the module is released under (almost always the Artistic license). Explain how you're going to use the module. And how that lines up with what the Artistic license allows you to do.
This all sounds like a bunch of work. And, honestly, it is. But, from experience, it's far less work than trying to reinvent the solution yourself. And once you get down that road once or twice, it should get progressively easier for each subsequent request, making it more and more worth it each time.
In the spirit of full disclosure, I'll point out that I got a virtual slap on the wrist from my employer's IP lawyer for not following each step (which is why I recommend following each step), though he still approved the use of the code. And this is a multi-billion-dollar publicly-traded corporation (deep-pockets theory of law applies). CYA seems to be the first thing we're taught when we join, and it seems to get repeated for those drafted into managerial roles. And still, the IP lawyer accepted the use of the module in question based on the artistic license. (I'm now in the process of trying to convince the law department to start issuing blanket approvals based on licenses, such as the artistic license, just to make things easier/faster.) It's still worth it to use a module instead of rewriting it every time. And that goes a thousand-fold for XML modules.
| [reply] |
I don't know anything about 'code contamination rules', I guess they don't apply in my environment. Does the concept extend to 'thought contamination rules'? Are you allowed to read a piece of 'contaminated' code (off site presumably) then apply what you learned to 'clean room' code that you write on site? Are you even allowed to visit places where contaminated code may reside (like PerlMonks)?
Most rules taken to the extreme are silly. You don't have to take "Not Invented Here" rules very far at all to see how silly they really are however.
Perl's payment curve coincides with its learning curve.
| [reply] |