On the other hand, I trust Perl more than I trust myself in understanding the features, so I want to state what I know about the code, in the sense of minimum requirements, but otherwise tell Perl "Do whatever you think is correct".I fail to see the benefit of that.
Suppose we had this scheme already in place, say since 5.8. You specify for a program "oh, give me 5.10 or anything newer, including its changes in behaviour". You did not include use strict;, because your program is doing some tricks that requires it to be off.
Then 5.12 came along, which defaults to enabling strict. Your program now fails to run. Would that have made you happy?
Of course, there will come a point in time when Perl deviates from its behaviour, but I see that as my problem and not as Perls problem.But it is Perls problem. Backwards compatability has an enormous value. It lowers the bar to write products in Perl. It lowers the bar to upgrade your Perl. Without backwards compatability, Perl would not even have been half so successful as it is now.
But backwards compatability is also holding us back. We keep having to support old features, and new syntax sometimes is convoluted because a more natural way of writing clashes with some obscure, mostly forgotten, syntax. Remember how long it took before // was accepted? The reason it took so long was because it could clash with existing syntax. We would have had // much earlier if we'd had something like Jesses proposal.
In reply to Re^5: Back to the __future__
by JavaFan
in thread Back to the __future__
by cdarke
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |