Re: Experimental features: autoderef vs postfix deref
by BrowserUk (Patriarch) on Jul 12, 2015 at 14:04 UTC
|
This made me wonder what if any "new syntax" added to Perl5 since 5.8 has actually become a useful, usable part of the language and not been backed out or hidden behind some obscure set of enablement requirements that mean its too much bother to be bothered with.
Given/when: been and gone; smart matching: decree absolute; autoderef: living on the edge; state:barely used, and flawed; say: a pain to enable; /r: never seen the need.
From my perspective, the only new feature that has earned its place is defined-OR (//).
So, when I read about new ego-driven fads like postfix deref I look back at the recent history and think: Meh! Why bother. It'll probably disappear up its own bum once the ego trip wears off anyway.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
{
my $closure;
sub x1{ $closure = shift if @_; $closure }
sub x2{ $closure = shift if @_; $closure }
};;
print x1( 123 ); print x2(); print x2(456); print x1();;
123
123
456
456
Or I can do: {
local our $closure;
sub x1{ $closure = shift if @_; $closure }
sub x2{ $closure = shift if @_; $closure }
};;
print x1( 123 ); print x2(); print x2(456); print x1();;
123
123
456
456
Or: sub x1{ our $closure = shift if @_; $closure } sub x2{ our $closure =
+shift if @_; $closure };;
print x1( 123 ); print x2(); print x2(456); print x1();;
123
123
456
456
Try that with state: sub x1{ state $closure = shift if @_; $closure }
sub x2{ state $closure = shift if @_; $closure };;
print x1( 123 ); print x2(); print x2(456); print x1();;
123
Use of uninitialized value in print at (eval 22) line 1, <STDIN> line
+14.
456
123
Or: sub x1{ state our $closure = shift if @_; $closure } sub x2{ state our
+ $closure = shift if @_; $closure };;
No such class our at (eval 23) line 1, near "{ state our"
No such class our at (eval 23) line 1, near "{ state our"
So, three different ways to do something that works; and a new mechanism specifically designed to replace them that doesn't.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
|
|
|
|
|
I agree with all you've said here. I've played with all the new features you stated, but none ever provided me with enough benefit over what existed and I was used to, so I gave them up quickly. However, I'm sure some people do find value in them, it's just that I don't so much.
I'm going to try postderef, but in any real code I'll stick to the old fashioned way as it's guaranteed backward compatible (CPANTesters) and I just can't see it being removed any time in the even non-forseeable future.
-stevieb
| [reply] [Watch: Dir/Any] |
|
Why is use 5.024 'a pain to enable'? And yes, people - for example, I - do use say, /r and unicode_strings, and __SUB__, and fc. I'm going to use posfix deref too, when the current bothersome incantations to enable it will go away. And also signatures.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Why is use 5.024 'a pain to enable'?
Because I'm currently on 5.18; one of my clients is on 5.14 and another on 5.10.
Because I'd have to remember which client's behalf I'm programming on; which version that client uses; which 'feeechers' that version supports; which 'mis-feechers' that version has dropped.
And then go through the whole damn game again when they decide to upgrade; and have to back out and replace the stuff that's 'gone away'.
Life's too short to ripple in the wind of every vanity project p5p allows through.
| [reply] [Watch: Dir/Any] |
|
|
|
Re: Experimental features: autoderef vs postfix deref
by Anonymous Monk on Jul 12, 2015 at 13:36 UTC
|
See here and here: it seems that postfix deref is on track to become non-experimental and autoderef to be removed.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Very helpful posts by both AnonyMonks, thanks. Does it go without saying that if it's been deemed non-experimental in blead that it's safe to use in prod code now, and ok to use in PerlMonks replies without applying the 'careful, experimental' blurb?
| [reply] [Watch: Dir/Any] |
|
|
|
|
|
Re: Experimental features: autoderef vs postfix deref
by stevieb (Canon) on Jul 13, 2015 at 19:28 UTC
|
For anyone interested, I've been doing some basic benching. Two of the tests are self-explanitory. The "no_braces" test is the same as "circumfix", except that it has all but the mandatory bracing removed. Over the next couple days, I'll do more elaborate testing that can be repeated easily. In this case, after numerous runs, I can only suspect that the 'no_braces' is slower consistently because perhaps perl has to do extra work to decide how to proceed. This is only a guess though. I don't know nearly enough about the guts to know for sure.
Result:
Rate no_braces circumfix postderef
no_braces 2.59/s -- -2% -7%
circumfix 2.64/s 2% -- -5%
postderef 2.78/s 7% 5% --
Benchmark code:
#!/usr/bin/perl
use warnings;
use strict;
use feature 'postderef';
no warnings 'experimental::postderef';
use Benchmark qw(cmpthese timethese);
my $count = 100000;
cmpthese(1000, {
'circumfix' => \&circumfix,
'postderef' => \&postderef,
'no_braces' => \&no_braces,
});
sub circumfix {
my ($h, $a, @a);
for (1..$count){
push @{$h->{$_}}, [$_];
}
for my $k (keys %{$h}){
for (@{$h->{$k}}){
push @{$a}, $_ for @{$_};
}
}
push @a, $_ for @{$a};
}
sub postderef {
my ($h, $a, @a);
for (1..$count){
push $h->{$_}->@*, [$_];
}
for my $k (keys $h->%*){
for ($h->{$k}->@*){
push $a->@*, $_ for $_->@*;
}
}
push @a, $_ for $a->@*;
}
sub no_braces {
my ($h, $a, @a);
for (1..$count){
push @{$h->{$_}}, [$_];
}
for my $k (keys %$h){
for (@{$h->{$k}}){
push @$a, $_ for @$_;
}
}
push @a, $_ for @$a;
}
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
I did run numerous times and the results were pretty consistent. I'll definitely do as you suggested to get a better idea, and will post back here with results.
| [reply] [Watch: Dir/Any] |
|
Interesting, but probably not very significant.
A more interesting figure, that is probably impossible to measure, is what performance affect has this 'feature' had upon code that doesn't use it?
| [reply] [Watch: Dir/Any] |
|
I thought that if you don't request the code, it isn't loaded. Can you explain what you mean? Would it be that even though the feature isn't use'd, it's still intertwined enough to have effects?
| [reply] [Watch: Dir/Any] [d/l] |
|
|
|
|
Re: Experimental features: autoderef vs postfix deref
by anonymized user 468275 (Curate) on Jul 14, 2015 at 11:26 UTC
|
All this chinese makes me jump in my goalseeking time machine, set the goal for "why did we ever want $, @, %?" and press the start button.
As the smoke clears from the TARDIS console, I find myself somewhere in Bell labs in the late sixties, when, along with hard rock, the unix shell was invented and variable names had to have a different syntax to filenames (a note to myself:nothing to do with reserved words after all).
Pressing the next button jumps me forward twenty years or so, when suddenly Perl is invented and needs to have a syntax for arrays and hashes.
But where is postfix? Not in this causality chain, so I reset the console and land somewhere in Palo Alto instead , where in a parallel Universe, a postfix addict invents Java ('.' instead of '->'). Suddenly, time and space collapse in causality violation and I am left asking myself whether the $ # % was a good idea in the first place. Given that & is enough to distinguish function calls from variable references, and that the shell doesn't get its hands on the Perl code, it seems to me that maybe Perl could have borrowed this part of the syntax from C instead of shell in the first place? But trying to make Perl look like Java won't help that, in my opinion.
| [reply] [Watch: Dir/Any] |
Re: Experimental features: autoderef vs postfix deref
by sundialsvc4 (Abbot) on Jul 13, 2015 at 17:22 UTC
|
I will frankly agree with you, BrowserUK. (Upvoted.)
The big problem that I have with most of these “fee-churs” is that they add a new “M” to “DWIM,” apparently just to save a few keystrokes. Most of the time, a programming language doesn’t really need another way to say the same thing. All that this really does, is to introduce yet-another element of functional ambiguity into the syntax ... which is especially a problem when the “correct” interpretation depends on (even for the moment ...) some obscure use clause.
Given that programmers have to maintain source-code libraries consisting of maybe hundreds of thousands of lines, it really isn’t a good thing for there to be more-than-one way to say one-thing. There probably will be no at-runtime difference, as the compiler might well translate both constructs into the same underlying perlguts. But, there is a pragmatic difference, caused both by the ambiguity and by the co-existence of “old” and “new,” within the same voluminous code-base. Only a very few, like “immediate-OR,” are both clean-enough and isolated-enough to be (IMHO) a genuine, relatively risk-averse, win.
Language features, however well-intentioned they may be, must be judged in a very long view. We do every day deal with vast code-bases that were constructed over the period of many years, even as the [Perl...] language itself evolved, as it were, “beneath their feet.” That source-code is worth many millions of currency-units. [Perl], itself, is not.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
|
To put it another way, though not very well: “TMTOWTDI ... now, pick one.”. It’s okay to have more than one approach to a problem, but not to have two or more syntactically-ambiguous ways to do the same thing.
Every language has its “crufts.” Perl, maybe, has more than a few. But you smile to yourself and say, “that’s just the way it is.” Speaking now purely from a software asset-management point of view, the one thing that I most do not want to see is: “That’s just the way it is, only maybe it isn’t.” Yeah, maybe in retrospect “that way” might not have been aesthetically best, but let’s all just live with it, for the sake of millions of lines already written. Don’t gratuitously tweak the compiler and then add an on/off switch to your tweak. Well-intentioned though your efforts might be, that just adds headache without aspirin. Now, within a massive block of source-code, we now have two different ways being done to accomplish the same thing in not quite the same way. Uh uh. Don’t do that to me...
| [reply] [Watch: Dir/Any] |