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.

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

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

Replies are listed 'Best First'.
Re: My day with Damian Conway
by frag (Hermit) on Jun 26, 2001 at 03:53 UTC

    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)Re: My day with Damian Conway
by tye (Sage) on Jun 26, 2001 at 09:11 UTC
    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")

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

Re: My day with Damian Conway
by tachyon (Chancellor) on Jun 30, 2001 at 16:08 UTC

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


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




Re: My day with Damian Conway
by beretboy (Chaplain) on Jun 25, 2001 at 04:16 UTC
    This module is quite enlightening. ++ petdance. I look foward to the ... operator!

    "Sanity is the playground of the unimaginative" -Unknown
Re: My day with Damian Conway
by busunsl (Vicar) on Jun 25, 2001 at 11:00 UTC
    So in Perl 6 the existing ... range operator will die?

    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")
Re: My day with Damian Conway
by mikeB (Friar) on Jun 25, 2001 at 19:36 UTC
    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?
      You need to get on the mailing list for The Chicago Perl Mongers. It was announced on the list for well over a month.

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

Re: My day with Damian Conway
by clemburg (Curate) on Jan 31, 2002 at 13:02 UTC

    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

Re: My day with Damian Conway
by Maclir (Curate) on Jun 25, 2001 at 23:10 UTC

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