note moritz <blockquote>actually I don't wanna get rid of the feature but of the syntax.</blockquote> <p>Then we are (mostly) in violent agreement.</p> <p>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: <code> $ perl -wE 'say for "a".."e"' a b c d e </code> <p>which might be used a bit more often than direct increment on strings.</p> <p>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:</p> <ul> <li>The flipflop (.. operator in scalar context) could have its own operator, making accidental usage of ranges in scalar context much less confusing</li> <li>[doc://reverse] should lose its magic dual functionality (list reversal vs. string reveral) depending on context. Perl 6 uses another function for string reversal ([http://doc.perl6.org/type/Str#flip|flip]), but other approaches are possible too.</li> <li>Whitespace is allowed between sigils and the name of the variable. There's no good reason to keep that.</li> <li>Indirect method call syntax. (This one is hard to remove).</li> <li>The control sequences for newish regex features are really obscure and hard to remember.</li> </ul> <p>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.</p> <p>(*) 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.</p> <!-- Node text goes above. Div tags should contain sig only --> <div class="pmsig"><div class="pmsig-616540"> [http://perl6.org/|Perl 6 - the future is here, just unevenly distributed] </div></div> 1019130 1019142