All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

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.

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.

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.

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.

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?