Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • They're all writing their extensions as CPAN modules.
    • by chromatic (983) on 2009.05.28 22:45 (#68823) Homepage Journal

      That's because they have no choice.

      • Exactly the opposite -- thanks to backwards compatibility, they *do* have a choice, and that's a big part of why they bother to contribute.

        • If Perl 5 had a better class declaration and management system in the core, there'd be no need for Mouse, Moose, Squirrel, and dozens of other modules in the Class:: namespace.

          That has nothing to do with backwards compatibility (at least in a positive way).

          • I agree that the profusion of OO support modules is a real waste. While I'm satisfied with blessed hashes and a bit of code generation or autoloading, people who want something more would benefit from having only one (or two or three?) solutions. On the other hand, if some half-baked Java clone had been added to the language 5 years ago (more syntax for pseudohashes?), the OO people probably wouldn't have created Moose at all. A lousy object system seems worse than an incomplete one.

            Backwards compatibi

          • What does core here mean? perl itself, or the bundled modules? If bundled, then there'd still be the need for the modules itself. If in perl itself, then we'd be stuck with it for a while. The fact that the common basics of Perl OO are very flexible is why we even got as far as having something as powerful as Moose. We're basically everything Scheme wanted to be. A small core (by which I mean the interpreter, not the distribution) with extensions living in libraries.

            Ordinary morality is for ordinary people. -- Aleister Crowley
      • I feel like I don't have a choice, but not for reasons you'd like. Perl tends to be very important and lots of things need it. As a result sysadmins get touchy about upgrading it because they don't know what will break. Sure, you get distros to include the new Perl, but sysadmins are also touchy about upgrading operating systems on production machines. However it is fairly easy to get those same sysadmins to agree to upgrading one Perl library. Particularly if it isn't being used by a lot of things oth

        • I invite you to consider the history of Lisp and Tcl, which took the same approach. "It's okay that there's no standard, built-in way to do $X. You can just roll your own! The rest of this thread will show you several different approaches before it falls apart in nitpickery."

          If 98% of maintainable Perl 5 programs start with the same two lines of code, I can make a good argument that those two lines are boilerplate that a future version of Perl 5 should remove.

          Sometimes the right default is useful.

          • If a future version of Perl 5 removes those two lines of code, I guarantee you that a lot of Perl will break. Worse yet, a lot of it is Perl depended on by those same sysadmins who drag their feet on upgrading Perl regularly because "upgrades are risky".

            I'd prefer that you not make their point for them. If you want to make a default more intelligent, get rid of the requirement for modules to return a true value. That is low risk. Applying strictures and warnings to everything by default is not.

            About the

          • I would see no problem with that if it was dependent on the user to declare their intended version. For example, couldn't 'use 5.010;' imply strict and warnings? Like it now implies all features in the 5.10.0 bundle?

            Ordinary morality is for ordinary people. -- Aleister Crowley