in reply to Re^4: On moving forward and breaking compatibility
in thread On moving forward and breaking compatibility

Let me explain another way.

There are six and a half billion people in the world, plus or minus a few million.

Of those six and a half billion people, a few million have perhaps written some Perl 5 code. That leaves six and a half billion people who might someday need to write some Perl 5.

Perl 5 can perfectly well detect typos and warn of ambiguous or dangerous or useless constructs that novice programmers are going to make all of the time because they don't know Perl very well, but Perl 5 by default is for darn sure not going to help them because a couple of Perl experts who've used Perl for a decade and a half (if not more) would have to figure out that something may have changed in a new version of Perl 5 and perform some combination of updating their existing code, testing their existing code with the new version, or not blindly upgrading to the new version and wow, what a horrible burden to put on experts, especially experts who themselves have made changes to Perl 5 itself.

Fortunately, we live in a world where making little improvements which could help billions of people from making mistakes and to recover from those mistakes more easily is less important than teaching those Perl experts how to run awk or sed over a handful of programs to insert the cryptic message no strict; at the top.

Warn people about changes, certainly. Announce deprecations. Yet don't tell me that the people using software written and distributed and modifiable and redistributable with liberty preserved should be able to hold improvements hostage in the name of "But I can't test myyyyyyyyy code!"

Replies are listed 'Best First'.
Re^6: On moving forward and breaking compatibility
by pemungkah (Priest) on Feb 15, 2010 at 05:01 UTC
    I'm not saying we should make code complex or expensive to develop so that no one could ever have a problem if they blindly updgraded.

    I'm talking about the difference between "You got this error and here's why and what will fix it" vs. "You got this error" (good luck finding out why and how to fix it) or worse, "You got an error" (good luck figuring out what, why, and how to fix it).

    If a little thought and effort will make it easier on the harried and hurried developer, which many are, it's a nice idea to do that. And if a little bit more will make it trivially simple to get out of a potentially bad situation, it's a really considerate thing to do.