Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Monday September 24, 2007
05:28 AM

Irrelevant internals

[ #34529 ]

I am so sick of seeing this conversation.

"I have a problem."
"Here's a handy solution to your problem!"
"That solution involves a totally irrelevant internal thing that doesn't actually effect me but I don't like it so I'm not going to use it."

For extra points they will continue to complain about the problem and how there are no good solutions.

Examples:

* It uses Module::(Build|Install)
* It's written in $programming_language
* It uses $framework
* There's a lot of open tickets in their tracker
* It's licensed with $licnese
* It's free but not Free
* $technology burned me three years ago and won't touch it since

Especially fun are the people who intentionally cripple their systems to purge the forbidden technologies and then complain when everything is so difficult and nothing works.

What do you do with human roadblocks like this? I figure just let them suffer, they seem to find meaning in it. Watch yourself for signs of this behavior.

Bill Odom once told me "the problem with coders is they care about code", and he's right. Who cares what it does inside the box?! You're not going to work on it, you're going to use it. If it solves your problem, just use it!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Especially frustrating when coders try to impose their personal agenda on an entire company (without being up-front about it, at least).

    I won't name names, but I know of a company that opted for Linux when they would have needed to move to Vista. The IT manager is telling people that Adobe Reader "isn't available" - when what he means is that it's insufficiently open/Open/whatever. And that's going to come back to bite him. It's not 1985. People can Google.
  • "... but it won't run on Perl 5.005!"

    People who do stupid things often die. Companies who do stupid things should have the grace to die messily and publicly so that we can mock them.

    • That's only an argument for CPAN modules :)

      And even I'm at the point where I think we probably should be shifting the goal post to 5.6.1 now...
      • That's only an argument for CPAN modules :)

        I consider it an argument against backporting in general. If you want to use community-developed software for free, fine. If you want free community support for that project, you should have the decency to stay up to date with the current version of that software as far as possible (or the latitude in your business plan to rely on the good fortune of finding a sucker -- I mean volunteer -- to do your dirty work for you).

        It's way past time free software stop

      • These days you're lucky if I'll give you 5.6.2.

        My recommended back target for normal modules (ie. not toolchain) is 5.8.3. Yes, a mere three years old. Hell, even the *previous* Debian stable has that.

        For toolchain stuff it's 5.5.4, 5.6.2 and 5.8.2.
        • Personally I always consider 5.8.1 my target. Depending on what the code does, it may work on earlier versions, but I cannot be bothered to support any earlier version if I need to care about characters vs bytes. Unicode matters; 5.8.1 is the earliest version that got it reasonably right; it’s a no-brainer.

    • I try to target 5.6 for most of my code, and 5.005 for some of it. And I'll also point out to people when their code assumes a later version of perl without declaring it as a pre-requisite. I don't require that they make the necessary changes, but I consider it to be helpful to point out when they're doing that. I certainly appreciate it when other people point it out in *my* code.

      Sometimes they care, and add "use 5.008". Sometimes they care, and fix the tiny insignificant bit of code that was breakin

  • Was this, perchance, prompted by my recently pointing out that if I were to use $module to fix something then I would have to use Module::Install?

    In that case, I don't have a problem (my code works fine, it breaks a buggy POD parser which will have no effect on real users), so that other module and Module::Install are inconvenient changes, not a handy solution. I'd rather spend my time reading, watching rugby, drinking beer, and writing new code than spend it fiddling with old code that works.

    I also ha