NPEREZ asks, "Who are these people that have a vested interested in Perl and yet do not participate?" Well, I guess until very recently I was one of them.
The core of my professional work is a set of C++ libraries. But there are 11,000 lines of Perl 5 code split across about 30 programs which are essential components supporting those libraries. Most of it is generating things, including 95,000 lines of C++ code and hundreds of makefiles, VC++ projects, etc. The Perl 5 I use is either the vendor-supplied Perl (on my Linux boxen and my MacBook) or ActiveState on Windows; my development environment requires that most of that 11,000 lines runs on every platform I use.
In this context, Perl 5 has just plain worked for me for the last decade. With a fresh Linux install it usually takes me about five minutes to get the modules I use off of CPAN and than I'm up and running. I can't recall ever having an issue with using a different version of Perl for this; it just has always worked, quickly and easily.
Given that, why would I have "participated" in steering Perl 5? I'm a busy guy, and Perl 5 has been steered perfectly for my purposes without my contribution. It took Perl 6 to draw me into the community. Now that I'm following a number of Perl blogs (thank you Iron Man), I'm taking an interest in Perl 5 development as well, because I'm excited about the newer modules I am learning about.
So I come to this issue from both sides. On the one hand, I'm very excited about new developments in Perl (both Perl 5 and Perl 6); I'm correspondingly disappointed that 5.10 has not been widely adopted, because that slows my own use of it. (Though after seemingly good results compiling a "personal" 5.10 on one of my Linux boxen, I may try switching to this approach, leaving the vendor Perl for the system to use and upgrading the version I use personally.)
On the other hand, I'd be pretty put out if someone gratuitously broke all my scripts. (The proposed idea of making "use strict" default would do it nicely, breaking all but the most recent.) I guess if the breakage could be controlled by a command line switch it would just be a minor nuisance. Otherwise the cost would likely be somewhere between days of work and simply refusing to ever update Perl 5 again.
Having just taken my first steps into the community, I don't feel like the me of six months ago somehow deserved to be screwed over just because I wasn't really part of the community then. From my perspective, the Perl community did a fantastic job of steering the language through 5.005, 5.6, and 5.8; to the extent there has been a bit of a fumble with 5.10, it seems to be the lack of updates more than the changes to the language. I'd like to see that great work continue along similar lines.
Subscribe to:
Post Comments (Atom)
Unless something terrible happens, there will be a sort-of default "use strict" in 5.12.
ReplyDeleteBefore you jump at me, however, let me explain. If you run your code on a perl 5.12 (or newer), it will run without strictures unless you enable them normally. It will likely run just the same as with 5.10 or older. If you explicitly request that your code requires perl 5.12 by doing a "use 5.12.0;" or "use 5.012000;", then strictures will be enabled automatically. This works the same as with the new features: "use 5.10.0;" will enable the "say" feature for you just like "use feature 'say';".
Since if you're going to use any recent features in your code, you'll likely have to "use 5.XXXX" anyway, it's valid to say that strictures are on by default. But since this is an effect with lexical scope, your legacy code won't be affected.
I am not understanding your grievance here. You are free to use whatever version of perl you like. Many businesses continue to use older versions without detriment. You also have taken the conscious step to actually test run a newer version of perl and liked the results. You also rely upon vendor supplied perls and are conscious of the versions they ship.
ReplyDeleteSo what is the problem? If new things are turned on by default, and it is a major release number, and it happens to break your stuff, no one is forcing you to upgrade. If your vendor does it without telling you, that is a problem with your vendor.
Perl is not immune to language enhancement. You would have the exact same issue with any number of languages and compiler versions. Why should Perl be treated any differently?
And I believe contrary to smueller with regards to version declarations. If you are using the newer versioned binary, that should be enough to indicate that you actually want the new features. They should be enabled by default. If you don't want them, we already have a lexical pragma to disable things like strict and warnings (aka. 'no').
A final word: Why upgrade if you aren't going to use the new features or behaviors presented? If it breaks your stuff (like smart match changes in 5.10.1), it is for a good reason. Suck it up and make the changes if you really want to use it. If not, you are free to remain on your previous versioned copy without incident. Perl core should not be stuck in this "perpetual twilight" (as someone commented). Your attitude and fear of change has got to go. No one is proposing malicious changes that will break everything, but some breakage is necessary. If you don't agree, please be assure that future perls will not reach back through time to break your old versioned perl.
@smueller: That actually sounds perfect for my purposes. Unchanged old code works the way it used to; new code can use the new features.
ReplyDelete@NPEREZ: I'd like to be able to use the latest Perl features when I write new Perl code. And at the same time, I'd like to avoid spending hours or even days updating my old code every time I get a new version of Perl. In any sort of sane world, these ideas should be mutually compatible.
ReplyDeleteTo the best of my knowledge, since C++ first stabilized in the early 90s, I have never had a piece of code invalidated by a change to the standard; and I would be surprised if the 0x version of the standard was any different. Occasionally updating a compiler breaks something, but these are always small things -- with my 300,000 lines of C++ codebase, it would normally be 15-30 minutes work to fix, tops. Even with my relatively small 11,000 line Perl codebase, mandatory "use strict" would almost certainly be more work to handle than the entire last decade of C++ compiler changes combined.
If it were as simple as adding "no 5.12.0" to the start of my old scripts, I'd be okay with that. (For the obvious reason that I could toss off a Perl script to do it automatically to all my Perl scripts.) Being forced to turn off each individual new feature one-by-one would be doable, I suppose, but seems extremely awkward.
(Maintaining multiple versions of Perl on all my various platforms really sounds like it would become a nightmare very quickly.)
The last comment regarding changing 300kl C++ code in 30 minutes to workaround or fix upgrade problem and more time on disabling strict in perl has no ground under. There is already intstrument for that 'no strict;'. Adding to any number of files will take no more than 10 minutes.
ReplyDeleteAnd you shouldn't do even that cuz you get strict and other new features only when you have explicit "use 5.008012;" which enables new features and help you avoid typing "use strict; use warnings; use x; use y; use z;" in all your modules.
Don't get horrified, people talking about smooth progress not regress. Nobody wants chaos.