Unfortunately, I arrived late, so I missed a lot of the things that Andy lists here. (Fortunately, I attended the OO and parsing classes that he taught. I highly recommend his classes; if you have an opportunity to take any of them, don't balk at the expense.)

Some thoughts:

• He discussed Perl Aikido: the gentle art of writing modules that helps other code to do the right thing. Because if it doesn't, it breaks.

• Concerning Perl 6 and OO: You may have heard that '->' will be replaced by '.', the dot. I really don't like the idea, primarily for readability and semantic connotations, but the fact that it comes from C++, Java and VB doesn't exactly improve my opinion of it. Anyway, Damian convinced me that a) I could (reluctantly) learn to live with it, b) not only should there be a pragma like "use syntax 'Perl 5';" but I can always write a Filter so that my own code can use arrows if I really can't live without them, c) Larry's mind is set on this one, so no whining.

• Some of the Perl 6 attribute/function names currently under consideration left a lot to be desired, although I've blanked out the memory of the worst ones. But unlike the ., these are still subject to change.

• There will be an honest-to-God switch statement in Perl 6, but probably won't use C's switch-case-break syntax, and there was some grumbling about the possible alternatives. Fallthroughs would have to be explicitly specified, which I thought would be a good thing.

• I was first put off by them, but now I'm convinced that Attributes (or Properties) will be a boon. He said to just think of them as adjectives that modify a noun (i.e. a variable or code). I'm especially looking forward to

  sub getdata : Exportable {
  
  }
  [download]

  ...which Damian said is being developed by someone who'll be putting it on CPAN RSN.

-- Frag.

            print << "END";
                Here's the text of the message I want to print.
                Note that I'm not flush left like I would have
                to be in Perl 5.  The amount of whitespace before
                the terminating "END" is stripped from the front
                of each line.
                END
[download]

(:

that's actually addressed (vaguely) in apocalypse 2, but if you think about it, it is unlikely to matter, as long as you are consistent. meaning, if you indent your text "\t\t" and your HERE "\t\t" then they are the same no matter what tabstop is.

if you care about perl6, the apocalypses are worth reading.

By default, if it has to dwim, it should dwim assuming that hard tabs are 8 spaces wide. This should not generally pose a problem, since most of the time the tabbing will be consistent throughout anyway, and no dwimming will be necessary. This puts the onus on people using nonstandard tabs to make sure they're consistent so that Perl doesn't have to guess.

Larry seems to be making a few assumptions that I find invalid. First, that "tabs are 8 spaces" is the most common setup. I actually find (to my amazement and disdain) that "tabs are 4 spaces" is the most common situation with lots of other variants flying about.

Second, that people aren't illogically, passionately opposed to moving to that standard when given a push. I find that some people are just that. Part of the problem is that some editing tools don't make it easy to indent your code "4 spaces at a time" unless you also have tabs set at 4 spaces each so forcing people to move to 8 spaces per tab also makes editing their code more difficult.

Third, that normal editing activities usually leave the "tabbedness" of lines similar. I work at a company where the policy is that tabs be converted to spaces before you check in your code so that we don't have to agree on how many spaces are in a tab (because we tried to agree and it was hopeless). I've seen how most of the developers edit code and it is trivial to set their environment so that tabs get turned to spaces. However, my editor shows me tabs and I can say that the tabbedness of related lines is very often not similar even though the lines look similarly indented to the people working on them. So if company policy in a small company can't make that happen, I have no hope for Perl 6 policy making that happen in the huge Perl community.

For example, most editors auto-indent lines in at least some situations. My editor defaults to using tabs for that but doesn't (by default) convert typed spaces to tabs. Other editors at work default to using spaces for auto-indent and don't convert typed tabs.

So I consider that use tabstop will be a required feature but the change will still result in a spate of confusion and adjustment. Don't get me wrong, the change is probably worth all of that, but it is a shame to not see better forethought on the matter.

        - tye (but my friends call me "Tye")

Bad assumption.

If I edit code, I tend to indent with spaces. Some editors automatically insert tabs. So I am dealing with code that behind the scenes has tabs, I edit normally, and now the code breaks with no visible mistake? Please let us not go there...

I never saw any great problem with this:

sub Unindent {

    my $unindent = shift;
    $unindent =~ s/^[ \t]+//gm;
  return $unindent;
}
...

    $message = Unindent <<"    MESSAGE";
    A fatal die was trapped by the $scriptname die nice routine:
    Time:          $datetime
    List name:     $list_name
    Script name:   $scriptname
    Package:       $package
    File:          $file
    Line Number:   $line
    Error Message: $message
    MESSAGE
    print $message;

....
[download]

cheers

tachyon </code>

Yes, that is fine. The problems come in when you want to strip some of the leading whitespace:

    print unindent( <<"    END" );
        Usage: $0 [flags] [args]
        Gropples the snarflog.
          -v       Verbose.
          -t mode  Mode of groppling to use.  "mode" can be:
                   fast  Minimize execution time.
                   hard  Maximize decryption time.
                   wide  Minimize alphabet size.
        Do not use on UTF8 files.
    END
[download]

Any attempt to write an unindent() for the above will run into problems in the face of 1) editors that insert tabs when maintenance work modifies the text, and 2) people who don't agree on how far apart tabstops should be set.

The only solution I've found that I like goes something like this:

sub unindent { s/^\s*\S//gm }

    print unindent( <<"    END" );
        .Usage: $0 [flags] [args]
        .Gropples the snarflog.
        .  -v       Verbose.
        .  -t mode  Mode of groppling to use.  "mode" can be:
        .           fast  Minimize execution time.
        .           hard  Maximize decryption time.
        .           wide  Minimize alphabet size.
        .Do not use on UTF8 files.
    END
[download]

        - tye (but my friends call me "Tye")

sub unindent {
    my $str = shift;
    (my $s) = $str =~ m/^(\s+)/;
    $str =~ s/^$s//gm;
  return $str;
}
[download]

This will look at the first line and extract that much leading whitespace from every line so does what you want without the .

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Well, I think nobody is using anyway.

Why would it have to die? One is a language contruct (or if you want, an operator with 0 operands), the other (the existing operator) is a binary infix operator. There cannot be any ambiguity.

-- Abigail

So, if I wasn't sure whether I wanted to use .. or ... as my range operator (because I hadn't recently read up on the differences), I'd just mark that part of the code as unfinished by typing: pre()...post() then later replace it with the correct range operator after I'd had time to do that research. q-:

        - tye (but my friends call me "Tye")

You need to get on the mailing list for The Chicago Perl Mongers. It was announced on the list for well over a month.

xoxo,
Andy
--
I was dreaming when I wrote this, so sue me if I go too fast.

He didn't specifically explain that golf in the extreme way we golf here is good, but rather that ``The fewer characters you type, the fewer characters you can get wrong.'' He claims that there's a linear correlation between the number of characters in a system's source code and how many bugs it has.

Seems like not only history is repeating ...

There are better references available for this fact ... see Re: Re: The qq{worse is better} approach (discussion) - Length of Code vs. Errors in Code.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Thanks, Bro Petdance.

Damian will be spending two days in Dallas this week, and I will attend, so I may add some notes here. Not only is it great to hear wisdom, literally at the feet of the gods, but as a recently transplanted Aussie, hearing that sweet accent will be wonderful . . .