Re: getting rid of special features

in reply to getting rid of costly special features

I do. It happens to align nicely to the way popular spreadsheet calculations label their columns, and many non-geeks can make sense of it.

What are the chances that one day we have a pragma unfeature which disables such stuff?

I hope the chances are low.

When maintaining code, I have to be aware of what all the operations do under all the pragmas in scope. Which is already complicated enough when dealing with nested scopes that have use bytes; and no bytes; in effect.

And then we strict, warnings, utf8 (and no, utf8 is not the opposite of "bytes", that would be too easy), use 5.010 and other versions. Oh, and can you remember which version enables strict by default? was it 5.12 or 5.14? Do you even remember where that is documented?

The proliferation of catch-all(-ish) pragmas like common::sense and Modern::Perl don't help at all, because none of them is a de-facto standard, so you have to remember (or read up) about each that you encounter in foreign code.

Long rant, short summary: The need for pragmas is an indication of design smell.

If we want to make Perl 5 actually simpler in the long run -- and I do think that's a worthy goal --, we shouldn't make it more complicated in the process.

So rather deprecate stuff (with long enough deprecation periods to give even slow-moving companies the chance to crawl along) than layer more complexity on top of it.

A finishing thought: I never had a bug in my code from 'z' incrementing to 'aa', and I've never seen a SoPW here at the monastery where that behavior caused a bug. A much more worthy target for deprecation would be this one here:

$ perl -wE '$_ = "ababc"; my $re = ""; say /(ab)/; say /\Q$re\E/'
ab
ab
[download]

That is, an empty regex matching the same as the previous match (instead of disallowing it, or matching the empty string), which is especially annoying if it's not obvious that $re is empty.

Update: Ok, I couldn't resist: Making Perl 5 simpler, more transparent and generally more modern requires boldness and breaking backwards compatibility. Since the Perl 5 community strongly values backwards compatibility, Perl 6 was created to take this pain off of Perl 5. These days, most Perl 5 hackers have lost faith in Perl 6 (for which I can't blame them), but if they do want a modern Perl, they will have to face at least some of the pain they were trying to avoid 13 years ago. There is no easy path that leads both to evolution and backwards compatibility, and missing out on either of those two will cause pain.

Perl 6 - the future is here, just unevenly distributed

Comment on Re: getting rid of special features Select or Download Code

Replies are listed 'Best First'.
Re^2: getting rid of special features by LanX (Saint) on Feb 17, 2013 at 14:10 UTC
> I do. It happens to align nicely to the way popular spreadsheet calculations label their columns, and many non-geeks can make sense of it. actually I don't wanna get rid of the feature but of the syntax. better something like `strinc()` which does the same. (EDIT: Out of millions of postincs only few are supposed to increment strings, no need to share the operator.) > an empty regex matching the same as the previous match (instead of disallowing it, or matching the empty string), which is especially annoying if it's not obvious that $re is empty. I'm using this productivelyš, but again I'd rather prefer another syntax, something like `m/$ŹLAST/` for matching the last successful regex. > So rather deprecate stuff (with long enough deprecation periods to give even slow-moving companies the chance to crawl along) than layer more complexity on top of it. we had a keynote talk about this in Riga ... ... but I asked about the chances that this really happens soon. These side-effects make translating Perl5 to other languages a pain in the *ss. perlito for instance gets it "wrong". If you think about the steps needed to mimic this behaviour in JS ... maybe with something like a function `postinc(variable)` which handles the cases it gets incredible complicated and slow for such a basic operation like ++, especially because JS can't do call-by-references. Cheers Rolf š) see Re^4: grep trouble (body of flip-flop range)	[reply] [d/l] [select]
Re^3: getting rid of special features by moritz (Cardinal) on Feb 17, 2013 at 15:39 UTC
actually I don't wanna get rid of the feature but of the syntax. Then we are (mostly) in violent agreement. I still think that ++ being special-cased for strings is a rather harmless example, and there is another argument for keeping it: It's nicely symmetric with how ranges of strings work: `$ perl -wE 'say for "a".."e"' a b c d e` [download] which might be used a bit more often than direct increment on strings. Now that we've already having this discussion, I'd like to point out some more Perl 5 features that could be reworked to much saner: The flipflop (.. operator in scalar context) could have its own operator, making accidental usage of ranges in scalar context much less confusing reverse should lose its magic dual functionality (list reversal vs. string reveral) depending on context. Perl 6 uses another function for string reversal (flip), but other approaches are possible too. Whitespace is allowed between sigils and the name of the variable. There's no good reason to keep that. Indirect method call syntax. (This one is hard to remove). The control sequences for newish regex features are really obscure and hard to remember. But in the long run, removing cruft is only a small part of evolving Perl 5. I firmly believe that in order to stay competitive, it needs a type system(), proper subroutine signatures and a less bare-bones OO system in core. () If the need for a type system isn't obvious to you, let me just tell you that at least 95% of all the character encoding trouble in Perl 5 could easily be avoided by having separate types for text strings and byte buffers. Perl 6 - the future is here, just unevenly distributed	[reply] [d/l]
Re^4: getting rid of special features by johngg (Canon) on Feb 17, 2013 at 18:26 UTC
`$ perl -wE 'say for "a".."e"' a b c d e` [download] It had never occurred to me before seeing a range in the context of this thread to try `$ perl -wE 'say for q{x} .. q{ac};' x y z aa ab ac` [download] Perl has me laughing out loud with amazement and delight sometimes :-) Cheers, JohnGG	[reply] [d/l] [select]
Re^5: getting rid of special features by soonix (Canon) on Feb 17, 2013 at 21:40 UTC
Re^6: getting rid of special features by LanX (Saint) on Feb 18, 2013 at 00:28 UTC
Some notes below your chosen depth have not been shown here
Re^4: getting rid of special features by LanX (Saint) on Feb 17, 2013 at 20:06 UTC
> It's nicely symmetric with how ranges of strings work: yes and no! `DB<115> $a="aa"; print --$a -1` [download] that much about orthogonality in Perl. :( Cheers Rolf	[reply] [d/l]
Re^5: getting rid of special features by moritz (Cardinal) on Feb 17, 2013 at 20:36 UTC
Re^6: getting rid of special features by LanX (Saint) on Feb 17, 2013 at 20:55 UTC
Re^4: getting rid of special features by LanX (Saint) on Feb 17, 2013 at 20:15 UTC
> But in the long run, removing cruft is only a small part of evolving Perl 5. I firmly believe that in order to stay competitive, it needs a type system(*), proper subroutine signatures and a less bare-bones OO system in core. actually typing a scalar `my int $a` would make translating `$a++` very easy and giving another approach to solve this. Cheers Rolf	[reply] [d/l] [select]
Re^3: getting rid of special features by CountZero (Bishop) on Feb 17, 2013 at 16:42 UTC
actually I don't wanna get rid of the feature but of the syntax. better something like `strinc()` which does the same. I find that a very PHP-like suggestion. Far easier to remember the different effects of `++` for strings and numerals, rather than remembering a different function and again another one for the pre-increment. We don't need different functions and operators for all different use-cases like PHP does. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James My blog: Imperial Deltronics	[reply] [d/l] [select]
Re^4: getting rid of special features by LanX (Saint) on Feb 17, 2013 at 19:58 UTC
My point is the huffman-coding principle. Incrementing numeric indices happens maybe 1_000 or even 1_000_000 times more often than incrementing strings. So for integers this operator has to be short. But the effort to learn and maintain string_increment with a core operator like `++` is far less economic. For that reason I agree that strinc() (or whatever notation suits the most) would pollute the namespace like in PHP, so it should be outsourced to a pragma or module. The inverse approach would be the 'no feature qwinc' I proposed, forcing ++ to croak on strings and allowing full backwards compatibility. Furthermore allowing optimizations within Perl and less headaches and far more performance when translating to other VMs. Cheers Rolf	[reply] [d/l]
Re^5: getting rid of special features by Anonymous Monk on Feb 17, 2013 at 23:37 UTC
Re^3: getting rid of special features by Anonymous Monk on Feb 17, 2013 at 14:32 UTC
These side-effects make translating Perl5 to other languages a pain in the ss.* And you've lost me :) translating perl to other languages shouldn't guide the design of perl, come on	[reply]
Re^4: getting rid of special features by moritz (Cardinal) on Feb 17, 2013 at 15:23 UTC
You are right mostly about that, but there are other reasons to abolish them. They make Perl 5 harder to learn, harder to write correctly, harder to read and contribute to its reputation as a language full of cruft. The fact that they make it harder to translate Perl 5 to other languages is at first merely another symptom of the problem. But if Perl 5 doesn't want to be tied to the C world forever, and wants to explore other environment (JVM/dalvik-only mobile phones and browsers, just to name two appealing ones), the lack of portability that those features introduce becomes a problem on its own. Perl 6 - the future is here, just unevenly distributed	[reply]
Re^5: getting rid of special features by Anonymous Monk on Feb 17, 2013 at 15:43 UTC
Re^6: getting rid of special features by moritz (Cardinal) on Feb 17, 2013 at 16:58 UTC
Some notes below your chosen depth have not been shown here
Re^4: getting rid of special features by LanX (Saint) on Feb 17, 2013 at 20:03 UTC
JS is nowadays not only the most widespread language... ... because of its minimality one should think of it as a VM with incredible efficient JIT performance. Now think of benchmarks where a "python2js" conversion runs 10 times faster than a "perl2js" because you can't use ++ but you need a method inc(), which has to handle a special case which is only known to a little minority of people ... Wouldn't you love to have a pragma telling the compiler: No Sir, I don't need that magic here! ? Cheers Rolf UPDATE: added quotes.	[reply]
Re^5: getting rid of special features by tobyink (Canon) on Feb 19, 2013 at 09:52 UTC
Re^6: getting rid of special features by LanX (Saint) on Feb 19, 2013 at 10:37 UTC
Re^5: getting rid of special features by Anonymous Monk on Feb 19, 2013 at 09:26 UTC
Re^3: getting rid of special features by ww (Archbishop) on Feb 17, 2013 at 16:33 UTC
"...something like `strinc`" `C:\>perl -E "sub strinc { $strToBeInc = shift; $strToBeInc++; return $strToBeInc; } my $str='a'; my $foo = strinc($str); say $foo;" b` [download] While I agree with what I think is one of moritz' points -- namely, that P5 is going to have to break backward-compat at some point... or stop improving and die -- I don't think we're there, yet, nor do I see how replicating the code behind `++` to provide a (duplicative) `strinc` is a plus, unless it allows removing a lot of cruft from `++`. If you didn't program your executable by toggling in binary, it wasn't really programming!	[reply] [d/l] [select]
Re^2: getting rid of special features by Anonymous Monk on Feb 17, 2013 at 13:42 UTC
... pumpkin all the way	[reply]

In Section Meditations