Slashdot Mirror


First Perl 6 Book is Out

prostoalex writes "O'Reilly Publishing presented Perl 6 Essentials, the first book to be dedicated to Perl 6, at the beginning of this month. Looking at the table of contents, it hardly looks like a valid replacement for Llama or Camel books. Chapter 1 is available online. The whole book is available to Safari subscribers." I'm sure we'll review it sooner or later.

9 of 75 comments (clear)

  1. Perl 6 is a mistake. by Anonymous Coward · · Score: 4, Insightful
    I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.

    One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

    The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

    Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

    On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

    I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

    Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD ^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

    1. Re:Perl 6 is a mistake. by cakoose · · Score: 2, Insightful

      So few words, so much ignorance...

      String -> '(' String ')' | ...

      try doing that with a regex

      Try doing that with an NFA, dumbass. An NFA cannot detect matching parentheses. A pushdown automaton can. This should be pretty obvious since your example is a grammar production of the context-free grammar style. PDAs are related to CFGs like NFAs/DFAs are related to regexes (though the relationship isn't as clean in the former case).

      Regexes aren't NFAs but regexes can be used to describe any regular language (and only regular languages) and NFAs can recognize any regular language (and only regular languages). They are "equivalent" in terms of theoretical computational power (the traditional definitions state that regexes generate languages and NFAs recognize them). Also, DFAs can recognize all and only the regular languages.

      However, I still don't understand why the grandparent poster said:

      I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code.

      If "linear code" means non-branching code, then I guess that that's true. What I don't get is how he/she is restricted to linear code. Regular code is turing-complete and therefore much more powerful than regular expressions. Regular expressions are more compact and map better to certain problems, but they are provably less "flexible".

      As a side note, I think that Larry Wall suggested calling them "patterns" instead of "regexes" because they are more powerful than regular expressions (though I'm sure the old terminology will still be used). This is fully described here.

    2. Re:Perl 6 is a mistake. by Anonymous Coward · · Score: 1, Insightful

      So in other words, you never liked Perl all that much in the first place. I honestly don't see what's wrong with variables that include $, %, and @. It's just a way of concisely throwing in some syntactic markers to allow you to have interesting and convenient syntax in other areas. Certainly other languages have similar things; for instance, C has an array dereference operator ("[" and "]"), and nobody complains about it, even though it really is basically the same concept. And then there's the "." operator for selection of members of structs. Again, basically the exact same type of thing, and nobody has a problem with it because they're very familiar with it already.

      But I guess what it boils down to is whether it is, in fact, better to have a "nice, clean, pure language". I would argue that it isn't. I don't have a nice, clean pure car. My car's engine is water cooled. That makes it more complicated and less reliable, but it also makes it more efficient. Also, the back brakes are of a different design than the front brakes. Again, it would be purer and cleaner and simpler to make them identical, since that would make it easier to understand them and work on them, but it's more efficient the way it is. And, while I'm at it, my body's metabolism involves the burning of oxygen, when in reality an anaerobic metabolism is much cleaner and simpler (and safer -- do you know how corrosive oxygen is? there's a reason behind health fanatics' taking massive doses of antioxidants). But again, the Kreb's cycle, despite being a very complicated process, is actually waaaay more efficient. So I think sometimes a more complex, less pure, less clean design can be a better design.

      Having said all that, Perl is easy and fun to learn if you're into the weird and wonderful ideas behind it. But, like progressive rock music, if you're not into it, it's just irritating and seems virtually impossible to learn. So perl is great on programmer efficiency because it can allow a programmer to get massive amounts of stuff done easily. But on the other hand, it's also quite bad for programmer efficiency because some people just don't get into the ideas behind it and thus find it excruciatingly hard to learn and use.

      By the way, one of the really dandy things, IMHO, about Perl 6 is this idea that every damned thing is a closure. Loop bodies are closures, even, if I remember correctly. This is really freaky and wonderful, but maybe just because once you learn about closures, you get addicted to them. Also, by the way, my own personal impression of Perl 6 is that it is actually making the language simpler and cleaner. At least, the everything-we-can-make-a-closure-is-a-closure idea gives me a feeling that some underlying things are being unified in a nice way. I started to wonder, actually, why every language doesn't do it that way, and I haven't come up with an answer yet, other than the idea that maybe it can't be compiled into efficient machine code.

  2. Cart Before the Horse by wdr1 · · Score: 0, Insightful

    'nuff said.

    work on the language, then write the book.

    --
    SlashSig Karma: Excellent (mostly affected by moderatio
    1. Re:Cart Before the Horse by dubStylee · · Score: 2, Insightful

      No, it's more like "show how the cart is being designed so you can help build it and/or begin to use it with the perl6ish pragma in perl5".

  3. Re:not *intended* to replace the camel book by ClosedSource · · Score: 3, Insightful

    You forgot ".. Annoyances" which is purchased by people who don't use the product described in the book.

  4. Re:Ruby has its own design mistakes by 73939133 · · Score: 1, Insightful

    When I pick up some Python code that's space-indented and edit it in my text editor with 3-space tabs, the Python compiler's going to magically guess that my tab-tab is equivalent to 6 spaces, is it?

    If you use tabs consistently for indentation, then it doesn't matter what you set them to, the Python code will remain valid and its meaning won't be affected.

    If you mix tabs and spaces, you need to use the same tab setting as the original author anyway or the code will look like garbage.

    The flip side of your problem is: what if changing the tab setting makes you misinterpret your code by changing the indentation to be inconsistent with your actual block structure?

    The short answer is: you shouldn't change the meaning of hard tabs--it causes lots of other problems. Just use a decent text editor that indents correctly with spaces and standard tabs. Almost all of them do these days.

    And, no, this just isn't a problem with Python. Space-based block structure may seem weird, but it works quite well.

  5. Re:Ruby has its own design mistakes by metamatic · · Score: 3, Insightful

    That's the problem, though. There's no such thing as "standard" tabs.

    --
    GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  6. Re:I'm just wondering... by gnat · · Score: 2, Insightful
    If you're going to have thoughts like these, could you please keep them to yourself? Some of us appreciate Allison, Elaine, Elizabeth, Kudra, and the other women in Perl for the great things they've done. I would like them to stay around and do more great things rather than be driven away because every time one of them comes to a conference she's nervously looking over their shoulder wondering which guy is the anonymous coward thinking about her boobs. Comments like yours set up a totally creepy environment for women.

    And if Allison doesn't post in this thread, it's not because she's thinking "great, men are finally noticing women's bodies and commenting publicly on them". It's because she's off working on open source.

    If anyone wants to talk to me about this at OSCON, I'd be happy to explain more forcefully just how much this coward's comment pisses me off.

    --Nat