use Perl

• DL$MT%DF@#(hhh (Score:1)

  by joejoe (8543)

  Wow, you really taught that guy I've never heard of a lesson!
  
  You know, I keep getting your articles through planet parrot in my RSS reader, and waaay too many of them are you doing this kind of petty bitching about what "some guy" said. I wouldn't care what you say either, but these things are being pumped out through planet parrot (and planet perl), which annoys me greatly.
  
  For what it's worth:
  for =$*IN -> $guess { ... }
  is a trainwreck. It's the =$* that gets me. I like the ->. I'm OK with the non
  • Re:DL$MT%DF@#(hhh (Score:1)

    by chromatic (983) on 2008.04.04 23:30 (#61990) Homepage Journal

    For what it's worth...

    I can imagine you'd find it frustrating if people so casually dismissed your work with superficial complaints, especially if their complaints demonstrate little attempt to understand what you're trying to do. Maybe I'm extra sensitive this month from dealing with an underdocumented SOA project with heaps of code generation, WSDL, and EJBs.

    Unary prefix = always iterates over an iterator. The * twigil always indicates a global variable. $*IN represents standard input. Now that you know enough to read that syntax in individual chunks, is it still line noise?

    I don't remember when STDIN became $*IN, but that was a while ago. The others have been in the Synopses for ages; they're pervasive consistencies throughout the language.

    It took me less than a minute to verify each piece of syntax, starting by typing dev.perl.org into the address bar, clicking a couple of links, and searching in the text of the relevant Synopses, and this is what I don't understand.

    Isn't it even faster to look up the documentation for a piece of syntax and read it than compose several snarky messages over several days on a mailing list? There've been dozens of articles about Perl 6 syntax over even the past two years.

    I'm sympathetic to the idea that some pieces of syntax have changed, but grabbing a piece of code directly from a Synopsis and complaining that you can't immediately and intuitively grasp every fine point of its meaning is awfully silly. Is that really how most programmers learn to code? Guesswork?

    Every character in that example is there for a reason. None of them are random punctuation strewn about. Every character and logical chunk of code there has a meaning, and I believe they're consistent throughout all of Perl 6 and, to people who've used the language or are at least familiar with the consistencies, they make code easier to skim and to understand, like any other form of abstraction.

    No one has to agree with me about any of those decisions. There have been several discussions on p6l (and in person) about particular choices of syntax. The syntax has changed in several cases, but there's always careful reasoning behind it in accordance with the design principles of Perl 6. Careful consistency is one of those principles. Immediate, pervasive clarity to Perl 6 novices is not.

    Maybe someone else needs to wave the flag of "Don't expect to grok every piece of Perl 6 example code until you start learning the language." If someone did that, I could write instead about the Parrot bugs I fix and the features I add; would that be more interesting to you? (This is a serious question by the way.)

    Reply to This

    Parent

    • Re: (Score:1)

      by joejoe (8543)

      I can certainly decipher that bit of code with the help of the docs/web (and did), but I really don't want to decipher it everytime I revisit that line. It's not about being a "novice": I expect to have to learn the language, but I'm not going to be able to "learn" punctuation. Maybe that's a limit for me only... I don't know. I know perl 5 pretty well, but I still can't reliably remember whether it's ~= or =~ for regular expressions, and $_ and the $ vars are the only perlvars I have memorized (though $/
      • Re: (Score:1)

        by chromatic (983)

        Perl 6 relies on sigils and operators, but our hope is that by gathering and grouping variables such as $*IN and %*ENV (I bet you can guess what that one is) and turning other Perl 5 magic globals into object properties, the conceptual weight of the system is much less. Hopefully at least they'll be easier to look up this way.

        Unfortunately, some people have trouble reading symbols. I have trouble reading code without judicious vertical whitespace to separate paragraphs, so Python can be a chore. (Is th
        • Re: (Score:1)

          by duff (16)

          I think I can see where joejoe is coming from. Perl is often compared to the english language and his is a good example of punctuation-blindness that writers of english seem to have. Witness the use of "im" instead of "I'm" and run-on sentences and that no one knows where to use a comma or a semicolon in their sentences. Et cetera. Perl suffers this malady more because it relies more on punctuation than english does.
          
          So maybe it's the modern (mis)use of the english language that has conditioned people to
          • Re: (Score:1)

            by chromatic (983)

            I have difficulty reading mathematic formulas. The variables keep getting jumbled. If I spent more time with a few formulas, I'd eventually memorize them. Some people are better at words than symbols, and, as programmers, they might find languages with fewer symbols easier to read. That might be the case for joejoe.

            Of course, English punctuation is mostly hints anyway. Just like you can represent Koine Greek without aspiration notation, you can represent written or spoken English without punctuation
          • Re: (Score:1)

            by joejoe (8543)

            What I obviously meant by not being able to learn punctuation is not being able to learn strings of punctuation as syntax. I am actually quite a stickler for proper use of commas and apostrophes (and I despise chat-speak abbreviations), and I don't believe my English usage is a problem in relation to my coding. Besides, one learns the rules of a natural language over years, but I typically need to learn a computer language over days or weeks (not master it, mind you, but at least read it).
            
            I have been usin