in reply to Experimental features: autoderef vs postfix deref

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.

  • Comment on Re: Experimental features: autoderef vs postfix deref

Replies are listed 'Best First'.
Re^2: Experimental features: autoderef vs postfix deref
by salva (Canon) on Jul 13, 2015 at 17:38 UTC

      I totally agree...

      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...