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

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.
  • I don't think chromatic is proposing that Perl start break back compat willy nilly. He's been quite clear that he wants to see Perl on a time-based release cycle with published deprecation schedules.

    Imagine if Perl release 4 times a year. Then if there was a desire to deprecate something, a release could say "feature X will be removed after 6 more releases, 18 months from now".

    That seems pretty reasonable.

    Furthermore, no one out there is jumping from 5.6 to 5.10 without some serious testing. Even with Perl'

    • Is "because fuck you a year from now" that much better than "because fuck you?" I like the way my Perl programs keep working when I copy them to a machine where the sysadmin has decided to install the "latest and greatest." The sysadmin likes the way I don't ask him to install an old Perl to un-break my working programs.

      • So you expect the Perl core folks instead to do all the work for you, and ensure that when you do something that's likely to be unsafe, it's safe anyway.

        That's ridiculous.

        • The Perl core folks can do whatever they want (as if they need my permission!), but their emphasis on backward compatibility saves me a lot of headaches, and those saved headaches are part of why I keep using Perl. How hard is this to understand? I'm not making demands or threats; I'm just trying to explain why, in a world with too many programming languages, I continue to use Perl for day-to-day tasks.

          • [Their] emphasis on backward compatibility saves me a lot of headaches, and those saved headaches are part of why I keep using Perl.

            That same relentless emphasis on backward compatibility creates a lot of headaches, too. How many security holes exist because two-arg open still works? Why do I have to write the same boilerplate every time I start a new Perl program to ask the compiler for help? Why can't we have a class keyword? Why is the return value of system() inconsistent with the rest of Perl? W

            • How many security holes exist because two-arg open still works?

              I have no idea. How many of my programs are easier to use because it still works? This seems like the same attitude that led the GNU folks to put in a non-STFU-able linker warning about using gets. The C folks got it right when they made cc and lint separate programs -- assume the user know what he is doing, but let him ask for hints.

              Why do I have to write the same boilerplate every time I start a new Perl program to ask the compiler for hel

              • If you were Perl's sole author, this would be an off-putting but legitimate statement.

                My status as one of hundreds of contributors makes it no less a tautology: if you want absolutely nothing to change, don't upgrade. You can't have both.

                • by educated_foo (3106) on 2009.03.05 22:01 (#67716) Journal

                  if you want absolutely nothing to change

                  Where did I say this?

                  don't upgrade.

                  Where did I say that I am sysadmin on all the machines I use?

                  I may be a dirty pinko commie about the real world, but I'm a software conservative. If Bob Sysadmin upgrades Perl to version X, and Jim-Bob Sysadmin keeps it at Y on a different machine, it's a waste of my time to maintain two versions of my scripts... er, programs. Perl's (past?) sometimes-painful focus on backward compatibility and portability is one of its main features.