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!
"... 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.
Re:My Favorite
Alias on 2007-09-24T22:38:56
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...Re:My Favorite
chromatic on 2007-09-25T00:43:39
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 stopped sucking up to leeches.
5.6.1?
schwern on 2007-09-26T22:00:07
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.Re:5.6.1?
Aristotle on 2007-09-27T09:42:57
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.
Re:My Favorite
drhyde on 2007-09-27T11:29:52
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 breaking on 5.6. Sometimes they don't care and do nothing, which is fine. And sometimes they care and get rude about it.
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 have other valid reasons for not using Module::Install (and Module::Build). The most important ones are that adding *yet another* module buildy thing (M::I) is pointless and just complicates matters for everyone, and that M::B doesn't work very well, although the reason for it existing is a good one and I wish it did work better cos then I'd use it for new modules.
