http://www.perlmonks.org?node_id=350308


in reply to Re: Re: How to Sell Perl 6
in thread How to Sell Perl 6

What kind of code that you have written today breaks tomorrow?
Almost all of the code I write uses one or both of the items I mention. All of that either becomes invalid, or changes meaning.

my %hash; $hash {key} = "foo"; # Illegal in Perl6, even after s/\$/%/ my $str = "99 miles to L.A."; print length ($str) + 1; # Prints 17 in Perl5, 3 in Perl6.

This is very basic stuff to write, which I do many, many times in code (and I guess many people use hashes, and use subs/methods in expressions).

Abigail

Replies are listed 'Best First'.
Re: Re: How to Sell Perl 6
by ysth (Canon) on May 04, 2004 at 18:29 UTC
    I tend to only reply to Abigail-II when I disagree; this isn't one of those cases. Using whitespace to control grouping is dumb, dumb, dumb; that's what parens are for. This is going to be an endless source of bugs for newbies (in addition to offputting non-newbies such as Abigail).

    I'd welcome hearing rebuttals the other side (but not enough to venture into the perl6 lists to hear it).

      After reading through Apocalypse 12, I finally started to get a handle on Abigail-II's concern, but I can't buy the argument. The vast majority of Perl code that I see does not use whitespace in quite the way Abigail-II does:

      %hash {foo} = 'bar'; # illegal in Perl 6, as Abigail points out # versus: %hash{foo} = 'bar'; # what the rest of the world does

      Admittedly, some people might find this to be a minor annoyance. Further, sometimes programmers do what Abigail does when trying to format a bunch of variables neatly. However, you can get around that if you really need to (IIRC):

      %hash .{foo} = 'bar'; # note the dot

      This minor inconvenience seems a small price to pay for the benefits we gain. Many of those benefits, in fact, are involved with giving Perl a powerful, robust OO model. This is one of Abigail's main complaints about Perl 5 -- and a reasonable one at that -- so I'm rather suprised that there's not more acceptance of the minor inconvenience. That's why I'm a bit confused about what Abigail's objections really are because I can't see this as being a serious issue.

      Cheers,
      Ovid

      New address of my CGI Course.

        That's why I'm a bit confused about what Abigail's objections really are because I can't see this as being a serious issue.

        I don't find the issue significant enough to discard the rest of Perl 6, but I have to admit it's one of the very few areas of the language that I really don't like.

        Actually I don't find the {} issue a problem personally. The heuristic of no-space = hash, space = block matches my code style, and the style of the vast majority of code that I come across, so it's not going to cause me any major hassles.

        The method argument stuff on the other hand I find much more personally problematical.

        I've written code in goodness knows how many languages over the last 20 odd years so I'd like to think I'm vaguely broad minded when it comes to syntax, but when I see code like this:

        a. $obj.method ($x + $y) + $z # means $obj.method(($x + $y) + $z) b. $obj.method($x + $y) + $z # means $obj.method($x + $y) + $z c. $obj.method + 1 # means ( $obj.method ) + 1 d. $obj.method +1 # means $obj.method( 1 ) e. $obj.method+1 # an error!

        my intuitions and Larry's are obviously seriously mismatched since I'd get (a), (d) and (e) wrong unless I am expending effort to think about it. I've shown it to a few other developers than I know and they all got (a), (d) and (e) wrong too.

        Now of course I can learn this syntax (and I'll probably have to :-) and the other interesting bits of Perl 6 mean that I'll still be giving the language some serious consideration - so why carry on about it.

        A few reasons:

        • Selfish first - I just don't like it!
        • I don't see that the significant white space increases clarity or conciseness enough to justify the learning curve. The rules seem fairly arbitrary to me (hmmm... maybe this is the last point with more words)
        • I want Perl 6 to be completely perfect and wonderful so I'm willing to spend some effort niggling about the little things :-)
        • The reaction of the developers I explained the white space rules to was unanimous horror. I expect that "it has these completely unintuitative rules for white space" to become part of the standard Perl 6 FUDer's armamentarium .
        • Perl 6 is a lot friendlier than Perl 5 to people coming from other languages except in this area of whitespace. I can't think of another language that has whitespace rules like this so it's going to make the learning curve nastier.
        • It's going to make switching the mental switch between Perl and Ruby/C/Lisp/Eiffel/Whatever and Perl harder for people like me who jump around between languages a fair bit.

        Basically every programming language out there has trained my eyes to ignore white space except for indentation. The latter is why I don't mind languages like Python or occam because their white space rules are a match for the informal coding style I'd be using in any other language.

        I'm going to have to retrain my eyes for Perl 6.

        I'm not looking forward to it because I don't see any major advantage that these rules are going to give me as a developer

        (Of course now is the time somebody will point out that there are some really nifty examples hidden in the depths of A12 - which I'll get around to reading properly Real Soon Now - which will probably result in a stupidly huge list of niggly comments that annoy everybody involved :-).

        This minor inconvenience
        It may look minor to you. But think how often you index in a hash in a typical program, and how often you call a method/subroutine on the LHS of an operator. All those minor inconveniences add up to one big inconvenience.
        for the benefits we gain. Many of those benefits, in fact, are involved with giving Perl a powerful, robust OO model.
        *blink* Then I must have understood the benefits of significant whitespace totally wrong. The hash index without whitespace gives us the ability to leave off parenthesis around an if clause. The sub/method whitespace rule gives us the ability to sometimes leave off parenthesis in an expression. It's completely unclear to me how the whitespace rules are being used to build an OO model.

        I might be willing to accept the significant whitespace rules if there was a significant gain. So far, every gain I've seen explained involves the ability to leave of parenthesis.

        Abigail

Re: Re: How to Sell Perl 6
by simonm (Vicar) on May 04, 2004 at 18:08 UTC
      What kind of code that you have written today breaks tomorrow?
    • I use hashes, and I index in them.
    • I use subroutine/method calls on the LHS of binary operators.

    Perhaps I'm mistaken, but looking at your examples, aren't they both aspects of the whitespace-between-tokens issue that was discussed here recently?

    Furthermore, I have been under the impression that old code was going to be parsed under a Perl-5-compatibility mode that presumably would use the old whitespace rules... Am I mistaken, or will this allow your old code to still work without change?