My day with Damian Conway

[petdance]

On Saturday, June 23rd, Damian Conway had a little free for all free-for-all workshop that he gave at College of DuPage in Wheaton, IL. He talked about a ton of different Perl topics, all of them enlightening. He's a great speaker, and I wish I could have gone to the 3-day class that he gave earlier in the week. Here are some random notes of interestingness that I scribbled down. Perhaps frag will want to add some of his own comments.

• ``$/ tells when to stop reading''
  We all know about the $/ variable, but a new light dawned when Damian said ``$/ tells when to stop reading''. That's why $/ = undef makes Perl read an entire file: There's no definition of when to stop reading. How clear it is now.

• Perl 6 may have the ... operator
  Perl 6 may have the ..., which Damian pronounced as the ``yada yada yada operator.'' You'd use it as a placeholder for undefined code like so:

          sub mangle {
                  ...
                  return 1;
          }
  

  Yes, that's a literal .... Executing mangle() would have Perl kick out a message like ``sub mangle is pending future code''.

• Typeglobs
  ``Typeglobs are like a box of chocolates'', he said, and then explained why in a way that let me finally understand the method behind the madness of typeglobs. Of course, typeglobs are going away in Perl 6.

• Perl's phases
  Big discussion of Perl's 5 phases: BEGIN, CHECK, INIT, execution and END, and when you'd want to use which one.

• The benefits of golf
  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.

• Qualifiers, not control structures
  In this code

          foreach ( @foo ) {
                  whack($_);
          }

  the foreach is a control structure.

  In this code:

          whack($_) foreach @foo;

  the foreach is a ``qualifier'', which is why you can't apply it to a block in that syntax.

• Perl optimizes a lot
  The Perl pseudocode has no ifs in it. Anywhere. ``How can that be?'' I asked. He then showed the following reduction:

          if ( $x > 50 ) {
                  do_something();
          }

  is the same as

          ($x > 50) && do_something();

  It's all just a lot of booleans in there.

• The use of the v notation
  Version strings are tracked with the v notation, like v5.6.0, which gives a string equivalent to chr(5).chr(6).chr(0). This is also handy for IP addresses, as in v127.0.0.1.

• Attributes
  Big discussion of attributes and the Attributes::* modules, most of which I didn't note because I don't see any direct application for them in my work. However, Perl 6 is going to make a LOT of use of attributes.

• Object-oriented design
  He presented his Spinal Tap-style list of Ten criteria for object-oriented design. This list will eventually be part of the standard Perl distro.

• What's coming in Perl 6
  Since Damian is sort of Larry's right hand man for language design issues, he's on top of all the changes that are going to be coming. Some of my favorites:
  • Here document improvements
    Here documents won't have to be flush left.

        while ($foo) {
            for ( @list ) {
                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
                } # for
        } # while

    Many of us literally applauded and cheered.

  • Typeglobs go away
    Everything will still be in symbol tables, but not as they are now. The fully qualified name of $foo will be the key in the symbol table, not like it is now, where $foo really means ``the scalar in the foo typeglob''. Also, lexical variables go into their own special symbol table MY.

  • Globals go away
    All the global punctuation variables will go away or become properties of something else. For instance, instead of setting $/, you'll modify the insep() attribute of the file handle in question.

And here is where my notes end. I wish I had a videotape of it. He's just great.

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

[frag]

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 {
  
  }
  

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

-- Frag.

[tye]

            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

So how many spaces are there in a tab? I guess we'll also have to have a new Perl 6 pragma: use tabstop 4;

(:

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

[Vynce]

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.

[tye]

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")

[tilly]

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

[tachyon]

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;

....

cheers

tachyon </code>

[tye]

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

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

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

[tachyon]

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

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

[beretboy]

This module is quite enlightening. ++ petdance. I look foward to the ... operator!

"Sanity is the playground of the unimaginative" -Unknown

[busunsl]

So in Perl 6 the existing ... range operator will die?

Well, I think nobody is using anyway.

[Abigail]

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

[tye]

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")

[mikeB]

How did I miss this????? That's just down the street from me!!! Is there somewhere I should be looking to find this type of thing?

[petdance]

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.

[clemburg]

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

[Maclir]

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