Slashdot Mirror

← Back to Stories (view on slashdot.org)

Run Perl 6 Today: Pugs 6.0.11 released

Posted by timothy on from the hump-into-the-future dept.

autrijus writes "I am delighted to announce that Pugs 6.0.11 is released, with experimental pugscc support to turn Perl 6 programs into stand-alone executables, as well as many new features. Pugs is an implementation of Perl 6, written in Haskell. For more information, see Pugs Apocryphon 1 and this perl.com interview."

97 comments

  1. Excellent by eyeye · · Score: 1

    I have been following this with interest. My only concern about this excellent project however is if using Haskell limits the potential developer base that might contribute.

    --
    Bush and Blair ate my sig!
    1. Re:Excellent by chromatic · · Score: 5, Interesting

      It may seem odd, but Pugs has actually inspired several developers to learn Haskell.

      --
      how to invest, a novice's guide
    2. Re:Excellent by Anonymous Coward · · Score: 0

      As cool as Haskell is (and other excellent functional languages like Erlang), there will always be that nastiness of a performance hit you take.

    3. Re:Excellent by smittyoneeach · · Score: 1

      Is there any research showing whether this "generally accepted" performance hit is intrinsic to languages with fat run-time environments, or does it have more to do with the nature of functional languages?

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    4. Re:Excellent by Anonymous Coward · · Score: 0

      It may be the case that some data structures are inherently faster to implement with destructive updates. But Haskell is fast enough for most cases. It's certainly faster than Perl for most things and typically about as fast as Java.

    5. Re:Excellent by Chalst · · Score: 1

      I don't know of any convincing evidence in that direction with respect to normal programming styles, but Siskind's Stalin compiler is a high-level (ie. its source language is scheme R4RS) compiler that performs extremely well when given code hand-optimised to make use of the compiler's brutally effective optimiser. To make the point, Siskind rewrote several standard UNIX utilities in Stalin and benchmarkes their performance: his code ran in about 25% of the time of those in the standard BSD distribution of the time.

    6. Re:Excellent by Anonymous Coward · · Score: 0

      Stalin certainly looks like a heavy duty compiler, but it is hard to find, it's extremely slow, doesn't even support macros (this was the killer for me), and then there's the name -- how about a lisp compiler named Hitler for an encore?

      Chicken is a far more versatile compiler, and is also quite fast. mzscheme is actually rather fast (tho it produces pretty large binaries) and it's as complete a scheme as it gets.

  2. is Perl 6 already standardised? by CaptainPinko · · Score: 1

    I mean is there already a full specification for the language? If so what are people waiting for, Parrot?

    --
    Your CPU is not doing anything else, at least do something.
    1. Re:is Perl 6 already standardised? by CaptainPinko · · Score: 5, Informative

      Has Perl 6 been specified?

      By December 2004, most of Perl 6 has been specified as a series of Synopses. Although not considered final, it is now stable enough to be implemented. Many of the Synopses are based on Larry's Apocalypses. Sometimes the design team releases Exegeses, which explain the meaning of Apocalypses. Pugs adheres to the Synopses, referring to Apocalypses or Exegeses when a Synopsis is unclear or imprecise.

      ---

      Still doesn't answer what the Perl6 folks are waiting for...

      --
      Your CPU is not doing anything else, at least do something.
    2. Re:is Perl 6 already standardised? by Anonymous Coward · · Score: 0

      They waiting for their pie in the sky.

      Just get it done guys. It will never be perfect.

      They're almost as bad as the Duke Nukem Forever idiots. You can't just keep redesigning for something better, you'll never get finished. Just do it.

    3. Re:is Perl 6 already standardised? by Anonymous Coward · · Score: 0

      They're almost as bad as the Duke Nukem Forever idiots. You can't just keep redesigning for something better, you'll never get finished. Just do it.

      yes we can, and we should. do you want another visual basic clone?

    4. Re:is Perl 6 already standardised? by smittyoneeach · · Score: 0
      Perl6 has got to rock like it ain't even funny to

      overcome the switching costs of giving up Perl5, for that community

      draw fresh mindshare towards TMTOWTDI, and way from the Pythonic TIORWTDI

      convince people that a language whose operator chart could be confused with the periodic table of elements is a Good Thing.
      A development effort led by anyone less than Larry would surely be a trip to the Wailing Wall. :)

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    5. Re:is Perl 6 already standardised? by autrijus · · Score: 2, Interesting
      Yes it is a major challange. :)

      There are several projects underway to migrate existing Perl 5 code to Perl 6 and Parrot, so no-one will be forced to give up Perl 5 and CPAN when it arrives. Indeed, were it not for CPAN, I think many people (me included) would stay around to work with Perl 6.

      As to fresh mindshare, Perl 6's optional strong typing and cleaner OO semantics does draw new people to join. It is also worth noting that Perl 6 has fewer precedence levels then Perl 5, and the operators are more streamlined as well.

    6. Re:is Perl 6 already standardised? by autrijus · · Score: 1

      Perl 6 is waiting mainly on a Perl6 to Parrot AST compiler, and the Parrot AST itself. See this draft milestones document for details.

  3. What happened to Parrot? by Anonymous Coward · · Score: 0

    I thought Perl6 had a language-independant runtime called Parrot. What happened to that?

    1. Re:What happened to Parrot? by Anonymous Coward · · Score: 2, Interesting

      I thought Perl6 had a language-independant runtime called Parrot. What happened to that?

      They're still working on it, and it looks like it's going to be pretty impressive when it's done. But they're writing it in C, which is great for fast code but very bad for rapid development. This is written in Haskell, and therefore has the opposite characteristics: the interpreter is apparently about 100 times slower than Perl5, but on the other hand they developed a working interpreter from scratch in one week.

      This isn't meant to replace Parrot, it's meant to provide an alternative implementation that can be used to work on things like Perl6 libraries so they'll be ready when the "real thing" finally appears.

    2. Re:What happened to Parrot? by Anonymous Coward · · Score: 1, Interesting

      This link explains the issues facing Parrot.

  4. Christ by Laxitive · · Score: 4, Funny


    An implementation of Perl 6.. in Haskell?

    There is something that feels.. oddly.. wrong about that. I can't put my finger on it.

    It's kind of like the feeling I got when I watched a porno with a hot girl and a really hairy guy.

    Hrm... I'll have to download this.

    -Laxitive

    1. Re:Christ by tdemark · · Score: 2, Funny

      It's kind of like the feeling I got when I watched a porno with a hot girl and a really hairy guy.

      Please don't compare Perl 6 and Ron Jeremy. I think Ron would be insulted.

    2. Re:Christ by KILNA · · Score: 2, Funny

      It's amazing that something so ugly can be so well endowed, and do such beautiful things. So where, exactly, does the analogy break down?

      --
      Error: PANTS NOT FOUND. Press <F1> to continue.
    3. Re:Christ by Anonymous Coward · · Score: 0

      Ron Jeremy used to be a pretty handsome guy (see this picture for example - no nudity) and he has a fairly large penis (see this picture - non-porn nudity). Being a handsome guy with large penis it was a natural idea to become a porn star. Then, when he got fat and old and ugly, he was even better for a porn star, because other fat and old and ugly men could fantasize about having sex with the same gorgeous girls who wouldn't ever look at them. So no, it is actually not amazing at all.

    4. Re:Christ by MaxQuordlepleen · · Score: 3, Funny

      Interestingly, this Perl-as-Uncle-Ron parallel seems to run on and on. Uncle Ron keeps trying to break into the "mainstream" and find "mass acceptance", and while he has done so in limited roles that play to his special strengths, at the end of the day he is a superstar of porn but a pretty sorry legitimate actor.

    5. Re:Christ by KILNA · · Score: 1

      When you're watching Ron in action, or reading Perl... it can be difficult to make out what's going on. It's often hairy, confusing, and messy. In the end, though it may not have been pretty, they get the job done and produce results.

      Ron has more humps than a pack of camels, perhaps he sould be the mascot for Perl 6.

      --
      Error: PANTS NOT FOUND. Press <F1> to continue.
    6. Re:Christ by Goldberg's+Pants · · Score: 1

      You're forgetting the fact he can also suck his own dick. Seriously, I've seen him do it. It's tough for him, what with his build, but there's definite tongue-dick connection.

      Enjoy your nightmares.

  5. More info by Anonymous Coward · · Score: 0

    See this journal: Perl 6 Implemented ... in Haskell for more info and links.

  6. Developers Needed by Anonymous Coward · · Score: 4, Informative

    The Pugs implementation effort is test-driven. In many cases, a few hours pass between the arrival of a new test and the implementation of a feature. So, anyone who knows (or would like to try) Perl 6 can contribute tests to Pugs. No knowledge of Haskell is required at all.

  7. perl6 is a mistake by keesh · · Score: 4, Interesting
    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. It's like Ada all over again! 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. 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.

    1. Re:perl6 is a mistake by BinLadenMyHero · · Score: 1

      I understand your points, but that doesn't necessarely mean the death of Perl. People can stick to Perl 5, just as they did with Winamp 2 when the ugly Winamp 3 came out.

    2. Re:perl6 is a mistake by Anonymous Coward · · Score: 2, Interesting

      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.

    3. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      >> Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal [lysator.liu.se] 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.

      The reason for this is because if you tell the interpreter what sort of data it is, it helps the interpreter do more optimizations with that data. Sure, it's not truly an integer, but at least you're helping the interpreter out but telling it how it can deal with the data.

      >> Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions.

      Of course, there is a lot of features in Perl. 200 ways to do one thing (which couldnt be considered a bad thing), but it's actually really cool, because it lets you stick to your own style more than other languages. Face it, perl should not be used unless you know what you are doing with it. It can get ugly, but it's powerful and can do certain tasks amazingly well, and better than any other language.

      Sure, it's bloated.. but the way it's being designed should make it so the bloat doesn't affect the speed or power.

      And you won't truly be able to appreciate Perl (especially 6), until you learn all the shortcuts [features] (not all, but..) . There is a lot to learn about the language before utilizing it's full power, but once you master it (if possible with perl), it becomes really fun.

    4. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      um, regex's aren't nfa's. nfa's can do, for example, make sure a string has the same number of opening ('s and )'s.

      so you'd have:

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

      try doing that with a regex

    5. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      regular expressions *are* [ND]FAs. Maybe you're thinking of Context Free grammer (FA + stack so you can do brace matching)?

    6. Re:perl6 is a mistake by Anonymous Coward · · Score: 0
      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.
    7. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      I'd move to Ruby right now, except it doesn't support Unicode. I really don't see any point in learning another language with no native Unicode support; I may as well stick with Perl 5.

      And like you, I'm not touching Python because of the stupid indentation block structuring. I mean, that's such a blatantly stupid idea... 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? And I'm not going to get irritated and confused by the fact that two indentations that look identical on the screen are seen differently by the compiler? Yeah, right, I believe that...

    8. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      I'd move to Ruby right now, except it doesn't support Unicode

      That's not a "design mistake", it's just a major feature that hasn't been added yet. This will be remedied in a future version of Ruby.

      A "design mistake" would be something error-prone and impossible to fix, like Python using indentation as part of the syntax.

    9. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Python is infintely better than Perl and Ruby precisely because of its use of indentation. Those who dislike it tend to be dumbfucks like yourself who wouldn't recognize a great, sexy programming language if it came up and sat on your face.

    10. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      That's not a "design mistake", it's just a major feature that hasn't been added yet. This will be remedied in a future version of Ruby.

      First, it hardly matters whether it is "just" a design mistake or a missing feature. If he needs the feature and it isn't available, he can't use the language. Second, Unicode tends to have all kinds of implications deep into the implementation of a language. They touch reflection, language syntax, regular expressions, file system, pickling, I/O etc. You can call it "just" a "missing feature" but it is one big feature. I would be surprised if Ruby got proper (i.e. integrated) Unicode support before the pretty major rewrite that will also add native threads.

      A "design mistake" would be something error-prone and impossible to fix, like Python using indentation as part of the syntax.

      Yeah, many people who have not tried it say that. Turns out that it is less error-prone because it eliminates a whole class of bugs that result from parens that do not follow the indentation.

    11. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      A "design mistake" would be something error-prone and impossible to fix, like Python using indentation as part of the syntax.

      That is not a "design mistake." Python was not originally meant to be a production language, it was meant as a teaching tool and as a teaching tool it used the whitespace block delimiters/quantifiers as a way to force programming newbies to learn to write readable code.

    12. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Turns out that it is less error-prone because it eliminates a whole class of bugs that result from parens that do not follow the indentation.

      Um, not a problem in real languages like lisp, where parens are unambiguous and notation is prefix. You can take an arbitrary lisp form, and a lisp-aware editor can (re)indent it correctly for you.

    13. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Yeah, many people who have not tried it say that. Turns out that it is less error-prone because it eliminates a whole class of bugs that result from parens that do not follow the indentation.

      The problem with that is that a lot of developers like myself have grown up with Fortran -> C -> C++ -> Perl -> Java, or some similar progression. We don't have a problem matching parenthesis. In fact, any decent text editor or IDE will help us match parens and get the indents looking the way we want them to. Hell, even vi can do that if used correctly!!

      It's not like there is nothing else in modern scripting languages that the python folks could have tried to fix. Why go back to the archaic practice of giving whitespace semantic meaning??

    14. Re:perl6 is a mistake by Anonymous Coward · · Score: 0
      Second, Unicode tends to have all kinds of implications deep into the implementation of a language. They touch reflection, language syntax, regular expressions, file system, pickling, I/O etc. You can call it "just" a "missing feature" but it is one big feature. I would be surprised if Ruby got proper (i.e. integrated) Unicode support before the pretty major rewrite that will also add native threads.

      Actually, this is one place where I think ruby is ahead of your average scripting language currently in the not-yet-supporting-Unicode state. The whole reason that Ruby exists (as in, the original itch the creator was scratching) is that when it was created, existing scripting languages handled Japanese exceedingly poorly. As a consequence, ruby has never been developed in a "all the world is ASCII, and what isn't is latin1" environment. This gives me hope that it will be much easier to add unicode support to ruby than you might think.
    15. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Actually, this is one place where I think ruby is ahead of your average scripting language currently in the not-yet-supporting-Unicode state.

      What scripting language doesn't support Unicode? BASH? Python, Perl and JavaScript all do.

    16. Re:perl6 is a mistake by Look+KG486 · · Score: 0
      The same goes for the syntax. All the switching between $, @ and % is really irritating

      This is part of the learning curve, but the symbolic representation of types is one of Perl's strengths. No need for Hungarian notation or weird naming schemes. One look and you know what you're working with. Not that other languages suffer without it, but I rather liked this aspect of Perl.

      However, I agree with your assessment of Perl for larger projects, and consequently, I've moved on to Java. As much as I love Perl, I found myself working harder than I needed to to build larger projects using OOP techniques. I.e., Perl isn't the right tool for anything larger than a page or two of code that handles a simple task.

      --

      "Play is the only way the highest intelligence of humankind can unfold." -- Joseph Chilton Pearce

    17. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      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.

    18. Re:perl6 is a mistake by Anonymous Coward · · Score: 1, Insightful

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

    19. Re:perl6 is a mistake by j0nkatz · · Score: 2, Interesting

      Correct and now Winamp is no longer around. It's development is dead. You just proved his point.

      --
      Don't mod me, bro'!!!!
    20. Re:perl6 is a mistake by Anonymous Coward · · Score: 1, Informative
      You can in fact do this with plain old Perl 5 regexes, as follows - to quote from Jeffrey Friedl's excellent Mastering Regular Expressions, 2nd Edition, p. 328-331:
      my $LevelN;
      $LevelN = qr/ \(( [^()] | (??{ $LevelN }) )* \) /x;
      This dynamic regex matches text within an arbitrarily-nested set of nested parentheses, by recursively 'calling' the compiled regex $LevelN from within itself - the left hand condition of the alternation is the exit condition. It works in Perl 5.6 or higher, maybe even earlier - just tested it.

      Of course, Perl 6 makes this sort of thing much easier and has a built-in Parse::RecDescent feature within regexes, but the overall complexity of the language is quite scary. I'm looking at OCaml, which is higher level than Perl (though with some features in modules and less syntactic sugar) and almost as fast as C/C++. It's also functional and OO, more details on my OCaml page
    21. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      As with perl5, one can expect that in perl6 although you get loads of convenience features you aren't required to use them.

      Chapter 4 of "Perl 6 Essentials" is a real eye-opener. It has the language explained _clearly_. No distracting run downs of the RFCs or what has been changed since 5. No forced example program. And a clear explanation. Of course, it only covers objects and classes simply, due to the lack of the appropriate apocalypse, but you get an idea.

      It's just not as complex as many people make it out to be - that includes the core design team =)

    22. Re:perl6 is a mistake by Anonymous Coward · · Score: 0
      Actually, I believe that as long as all the lines at a given level are indented the same, the actual amount of indenting is irrelevant. Example:
      for(1):
      for(2): # indented two spaces
      for(3): # indented five spaces
      for(4): # same as for(2)
      for(5): # note different than for(3)
      The accepted standard is 4 spaces per indent. And really, most programmers tend to write something similar anyway, Python just forces you to at least make an attempt at making the code readable.
    23. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      for(1): # indented three spaces
      for(2): # indented two tabs
      for(3): # indented six spaces
      for(4): # indented one tab

      Quick quiz: Which lines are in which blocks?

      Followup: How was I supposed to know that looking at the screen?

    24. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Actually, I believe that as long as all the lines at a given level are indented the same, the actual amount of indenting is irrelevant.

      Unless it's new, that's not true. My first experience with python was copying a script from a webpage, putting it in a file, and getting a runtime error.

      Turned out the browser had stuck five spaces in front of each line. I went through and pulled the whole text block to the left so that the leftmost line was in column 0 and it worked properly.

      Maybe it has been fixed and there's just alot of animosity from people who tried it too early.

    25. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Ruby is pretty nice. I was using it way back when nobody knew about it.

      It has one major problem that kept me from using it all the time: It's slow. It's slower than either Perl or Python (which is a dog).

    26. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Just the opposite. Because the Ruby guy is japanese, he has a hatred of Unicode and instead prefers the older encodings.

    27. Re:perl6 is a mistake by darnok · · Score: 1

      I agree with your sentiments entirely.

      I've been using Perl since the mid-90s; I can clearly recall the Perl 4 days, and I've written some reasonably sizeable systems with Perl 5.

      That said, I'm also looking at switching my people from Perl to either Ruby or Python.

      Things I love about Perl that I'll be sorry to walk away from:
      - CPAN; an amazing resource
      - for 100 line scripts, the ability to code as quickly as I can type, with few errors when I try to run for the first time
      - Perl's ability to bolt stuff together that was never meant to be bolted together
      - DBI model; it's so simple and elegant
      - regular expressions; don't know why, but Perl's regex's seem to be more natural than any other language's equivalent

      Things I'll be glad to put behind me:
      - how easy it is to write unsupportable code with Perl. I've lost count of how many times I've had to get people to rewrite working Perl code to make it comprehensible
      - the OO model; it's a bad bolt-on at best
      - "sacred code" (see two points above). Several times, I've come across "sacred code" written in Perl. It works now, but every time anyone tries to alter it, it breaks in unexpected ways. Yep, I/we could walk through it with the debugger to work out how it does its magic; nope, it often takes so long that you're better to take the hit and rewrite from scratch
      - TMTOWTDI. As a concept, it's fine, but being able to code the same small piece of functionality in 143 ways using 37 different functions kills supportability
      - the books. I don't know how many Perl books there are, but only a small percentage seem to push any sort of sensible approach to coding in the large. Damian Conway's "Object Oriented Perl" is a gem; a truly great coding book that shows people how to write scalable maintainable Perl. Many others seem to focus on cool ways to solve a small problem in very few lines of code, which gives readers the impression that this is actually a desirable way for coders to code

      I'll keep an eye on Perl 6, but I suspect it'll break a lot of CPAN libraries. If so, then the most compelling reason to use Perl will disappear with it.

    28. Re:perl6 is a mistake by Rayder · · Score: 1

      Being a lover of smalltalk, yes, Ruby is really nice, but lacks the passion (and orthogonality) I found in Smalltalk where every day you get surprised by something new you didn't know or by looking at how clever the architecture is.

      Recently I've discovered Perl (after beign bored with Ruby), and I'm amazed, it has a steepy learning curve, but every day I learn new ways to do things in a more compact (but illegible for the untrained eye) and smart way possible. And the infinite wisdom you can find in CPAN.

      For me Perl is as fun as Smalltalk was.

    29. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Why go back to the archaic practice of giving whitespace semantic meaning??

      Ithinkthearchaicpracticeisactuallyignoringwhites pa ce.
      Atleast,IrememberwritingBASIClikethiswhenIwas akid, anditworked.

      Note that Haskell, the language in which Perl6 is now implemented, is also (optionally) whitespace-sensitive.

    30. Re:perl6 is a mistake by Anonymous Coward · · Score: 1, Informative

      That said, I'm also looking at switching my people from Perl to either Ruby or Python.

      If you use Parrot implementations of Ruby or Python in the future, you'll be able to freely mix Perl 5, Perl 6, Ruby, Python, Tcl, et al. Which means that:

      Things I love about Perl that I'll be sorry to walk away from:
      - CPAN; an amazing resource

      You will have access to any CPAN module from any supported language using your language of choice native syntax.

      - for 100 line scripts, the ability to code as quickly as I can type, with few errors when I try to run for the first time

      You will be able to write those pieces in Perl 5 or Perl 6 without losing any interoperability with other supported languages.

      - Perl's ability to bolt stuff together that was never meant to be bolted together

      You will be able to use Perl 5 or Perl 6 for that, or other languages in case Parrot itself inherits said ability to your satisfaction.

      - DBI model; it's so simple and elegant

      Using Parrot implementation of Python, you will be able to write:

      dbh = Perl.DBI.connect("dbi:Pg:dbname=yourdb", "user", "pass")

      and have a Perl object referenced by your Python variable, with correct DBI semantics but with native Python syntax.

      - regular expressions; don't know why, but Perl's regex's seem to be more natural than any other language's equivalent

      Perl 5 regular expressions, as well as Perl 6 rules, will be both available directly in Parrot.

      I am a die-hard Perl guy, I will use Perl 6, but I am glad that no one will have to use it to cooperate with me. You will be able to write in Python, someone else in Ruby, another guy in Perl 5 and me in Perl 6, and still we'll be able to write our own CPAN module together and everyone will be able to use it not even thinking about the languages it was written in. This is something like .NET, only it will work and will be Free.

    31. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Please don't feed the trolls you idiot. Thank you.

    32. Re:perl6 is a mistake by yarbo · · Score: 1

      you've never made this mistake in C/C++?

      while (condition);
      {
      do_stuff();
      }

      or this one

      for (...)
      statement1;
      statement2;

      those mistakes can't happen in Python. A whole class of bugs eliminated, and all you have to do is indent your code (you don't do that anyway?!)

    33. Re:perl6 is a mistake by IpalindromeI · · Score: 1

      Ignore this troll. This post shows up in every Perl 6 article.

      --

      --
      Promoting critical thinking since 1994.
    34. Re:perl6 is a mistake by smittyoneeach · · Score: 1

      If you use tabs consistently for indentation

      Repeat after me:Tabs Are Evil

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    35. Re:perl6 is a mistake by Anonymous Coward · · Score: 0
      This is the classic example cited by python users, and I will grant you that I consider the first example to be a bug in the C language specification for allowing a blank statements other than {} to be used in an if, for or while statement. However, I should point out that lint will catch empty conditional statements, and indent will properly align the text in the second example.

      The main reasons I prefer a C-like syntax over a python-like syntax are as follows:

      • In my opinion, brace matching editors improve both readability and editability. There's no guesswork even if a function goes off of the screen*: you just hit brace matcher, and boom you're at the correct matching brace (* Before the flames start, keep in mind that I agree that functions shouldn't be that big, but that's not going to stop it from happening).
      • Braces allow you to write compact code on a single line. This is useful when you're instructing newbies over mud/irc, and it's also useful when you're evaluating expressions on a commandline that does not support line continuations.
      • You cannot see whitespace. Having flow control depend heavily upon something you cannot see bothers me.

      I'd also like to address the notion of typos as a class of bugs with a single quote (sorry, I don't know who said this. Maybe it was me?):

      "If it's not tested, it's broken."

      If you don't test your code incrementally, then you're not really writing software; you're writing bugware. There is no excuse for lack of incremental unit tests. You cannot rely on your language to eliminate bugs, because you're still going to make a few dozen typos per thousand lines of code. Sometimes these will be harmless, but other times they'll result in catastrophic failure.

    36. Re:perl6 is a mistake by yarbo · · Score: 1

      That would mean it has a shallow learning curve. If it was steep, you would learn everything in a short period of time.

    37. Re:perl6 is a mistake by yarbo · · Score: 1
      I've worked with people, and found that trying to force indent on them is very hard, for some reason. Forcing splint on a partner I had for a project was impossible (hell, he even started disabling some of the warnings, but that's another story).

      Indent will fix the indentation, but who is going to compare the before and after to see if something visibly changed scope?

      Besides, Python will let you write complicated things on a single line, provided that you don't use nested loops or assignments in conditionals. You can separate single statements on a single line with semicolons.

      If you're worried about mixing tabs and spaces, you can run python -tt and it'll throw an exception if tabs and spaces are mixed at any point.

      Btw, I think that picking unit tests that cover every line of code in all circumstances can be hard, and not everyone can be expected to write code that'll detect scope errors like the ones I listed. Sometimes those bugs will slip, and I think languages that enforce indentation are doing the right thing. There may be wonderful optional programs and unit testing packages, but many users can't be bothered, and it's nice if a language can force certain people to do things the right way.

      Maybe I'm just bitter because no one I work with will bother incrementally testing, unit testing, running lint, or following indentation standards if not forced. Maybe most people don't need it, I just know people around me need it...

    38. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      YHBT. YHL. HAND. YFI!

      (YFI means: "you fucking idiot" - I mean seriously, do you morons have to feed the trolls in every fucking story about Perl dragging the whole damn thread completely off-topic? Read this thread and then this one. Read the entire threads. Are you fucking proud of yourself now, you God damn imbecile? "Look, mom, I fed the troll on Slashdot!" You are just pathetic!)

    39. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Just as a minor point: it makes no difference whether you require indentation or braces, as long as one is required. The whole problem is the fact that C allows you to shoot yourself in the foot too easily. Sure, it's convenient to write "if (x) y;", but it won't really kill anyone to have to write "if (x) { y; };" instead, and that's essentially what python is making you do with whitespace, except it doesn't require the explicit keystrokes to type the {}'s.

      If the next C standard were to require {}'s for all conditional statements, then everybody's favorite editor would suddenly start supporting automatic brace insertion, and there would be no difference from a typing perspective. I'm sure the counter argument could also be made that if Python were to gain more momentum, everybody's favorite editor would support searching on indentaion level change. Really it's just a matter of preference. It would be fairly trivial to write a C-like frontend for Python or a Python-like frontend for C.

    40. Re:perl6 is a mistake by yarbo · · Score: 1

      But in Python, you CAN put a statement on the same line as a conditional, but you're limited to one liners (which can be more than one statement).
      you can write 'if y:x'
      or you can write 'if y:x;x;x;x;x;x;'

    41. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      I see you are trying to be the righteous idiot today. Fucktard.

    42. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      I'm sorry if I made myself unclear. I was suggesting that I would like to see a future C specification that requires the use of {} for all conditionals. The "if (x) y;" versus "if (x) { y; };" examples were to illustrate the additional characters that would be required if the C specification were to change. Such a change would make it impossible to typo the errors you pointed out a few posts back.

      My reference to Python was to say that a change in whitespace indentation level is functionally equivalent to a pair of braces. The statement was not intended to claim that you cannot use a single line if statement. Again, sorry if I made myself unclear.

    43. Re:perl6 is a mistake by autrijus · · Score: 1
      I would not have worked on Perl 6 if it will break my 111 CPAN modules. So yes, we'll find a way to run CPAN.

      Perl 6 also eliminated a large amount of @{[]} unreadable code -- see Pugs's modules/ and ext/ directory for examples that may be compared directly with equivalent Perl 5 modules.

    44. Re:perl6 is a mistake by ahdeoz · · Score: 2, Insightful

      And when world communism is finally implemented for real, there will be no poor or hungry on unhappy or unhealthy and anything that doesn't accomplish all this isn't really communism.

    45. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Not new, but true. If I got it, the problem in your case was that the main lines had some spaces before them. They must be at zero-indentation, that's the only limitation. Other blocks just need to be consistent within theirselves.

    46. Re:perl6 is a mistake by Anonymous Coward · · Score: 0
      Aww, poor Ruby.

      Seriously, quit being so silly.

    47. Re:perl6 is a mistake by Anonymous Coward · · Score: 0

      Nice troll. It is always pasted in response to Perl-related articles. Can we please mod it down, now? Thanks.

    48. Re:perl6 is a mistake by ajs · · Score: 1
      "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."

      First off, let's drop the word "script". It has no place in informed conversation, as it has no formal definition. Originaly the term meant logic-free execution of what would otherwise be command-line operations. Later, shells became capable of logic, so that definition wandered to include any run-time interpreted, high-level code which used existing programs to do its work. Then Perl came along and changed everything. Perl is non run-time interpreted, but it still feels "scriptish" in the sense that it is aware of the system its working with and makes its tools available to you.

      Now languages exist across the spectrum from Perl to Ruby to Scheme to Java. They can all be called "scripting" languages if you want, but the term has lost its meaning. It's just a word that you use to refer to a language that you personally don't take seriously.

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

      I liked the way Perl approached OO. It was a decidedly tentative approach. Where many languages added OO features by emulating C++ (the OO lingua franca of the early 90s), Perl didn't buy into that. It simply added all of the features that you would need to BUILD an OO system, but provided no object system, high-level OO abstractions, core library support, etc.

      Now that choice is paying off. Perl 6 can look back acrosss the last 10 years and see all the ways that Perl's OO tools were used, and select the most successful strategies to codify into the language. Perl 6 is also pulling from other languages where their features have proven useful. So, for example, Ruby mixins work quite well, and Perl 6 will adapt into its object model.

      "Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge;"

      You clearly don't know Perl 6. The object system is a complete re-design and resembles a blend of some Perl 5 best practices, Ruby, and Smalltalk. It's NOT a pile of kludges at all (unless, as with "script", you'd simply like to continue using what you consider a derogitory word without any basis in fact).

      "I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much)."

      If whitespace scares you, you are doing yourself a disservice. I'm not terribly fond of Python, but it's not because of the whitespace thing. That was just difficult to get over at first, but we've all been writing pseudo-code using whitespace for blocking for decades, so it's not THAT hard to get used to.

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

      Well, for starters, there's no such thing as a "keys array" in either Perl 5 or Perl 6. You treat the return value of the keys method as an array in Perl 6, but to think of them as an array up-front is incorrect. That's probably the source of your confusion right there. You can do this in Perl 6:

      $nkeys=%hash<subhash>.size

      I'm sure you'll agree that that's not to hard to remember.

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

      If you find @, $, % hard to type, then I'm not sure I can help you. You did say you'd been programming in Perl since the pink camel?

      "Perl was only designed for the three data types, and adding more is a mess."

      Here you're way off base. Perl 5 supports about a dozen data-types, but the most often used are:

      • scalar
  8. Gotta love FOSS by Look+KG486 · · Score: 0
    Pugs is an implementation of Perl 6, written in Haskell.

    1) Think up Pugs
    2) Write it in Haskell
    3) Get an implementation of Perl 6
    4) ???
    5) Profit

    --

    "Play is the only way the highest intelligence of humankind can unfold." -- Joseph Chilton Pearce

    1. Re:Gotta love FOSS by FidelCatsro · · Score: 1

      4) satisfaction for giving something to the community
      5) offerd high paying development job due to portfolio
      6) profit

      --
      The only things certain in war are Propaganda and Death. You can never be sure which is which though
  9. perl6 is not a mistake by Yobgod+Ababua · · Score: 4, Insightful

    Well, I can tell you have some pretty strong feelings on this subject. I'd just like to add a few comments from my perspective as another long time Perl user...

    Let me start by saying that I've read all of the perl6 documents with great interest and have almost universally been pleased with the changes that are being made. In all cases, I appreciate how most of the decisions are being made and that the concepts of useability and clarity are taken as important overarching goals. As an example, if you actually read apoc 5 which you linked to as an example of "smoking crack", you'll see that one of the main goals is "better huffman coding" - ie: making frequent tasks easier to express than infrequent tasks and that another is to make regular expressions more readable and maintainable and less like line noise. These, to me, are eminantly admirable goals in a scripting language.

    On OO, Note that Perl6, unlike Perl5, is being rewritten with OO at its core, not as an expansion to the previous "nasty hack".
    Note also that the perl6 team shares many of your issues with perl5's OO implementation and wants perl6 to be better: Apocalypse 12.

    Similarly, when you complain about $,@,% and how confusing they are, you seem to be complaining about perl5isms that perl6 is dedicated to addressing...

    In answer to your length of the keys array of a hash question, just use (keys %hash) in a scalar context, or (keys %hash).length. In your specific case, because the hash in inside another hash, you're looking at something like (keys $hash{"key"}).length; ... which doesn't seem particularly brain melting to me, especially compared to perl5. I also don't see this threatened horde of new datatypes you seem so angry about. I really recommend that people interested in what these differences will bring read the Exegesises, where equivalent perl5 and perl6 code is usually compared.

    "const int $var = 27;" ? Did you mean something like "my int $var is constant = 27;"? What specifically do you mean when you say that it isn't entirely constant or entirely an integer, and why does it matter?

    I completely have no understanding of why perl6 would please "the managers" or what this "one thing that makes perl5 special" is that you think is being lost. As far as I can tell, perl6 keeps everything that I thought made perl5 special and aims to clean up many of the things that make it a PITA.

    "It can't do what it wants to do whilst still being based upon a nasty mess." Isn't that why perl6 is a complete rewrite? What unholy mess are you referring to? From your post, I don't believe that you're one to be swayed from your beliefs, but many of your arguments appear on the surface to be based more on emotional response than factual backing...

    1. Re:perl6 is not a mistake by Anonymous Coward · · Score: 0

      YHBT. YHL. HAND.

    2. Re:perl6 is not a mistake by Black+Perl · · Score: 1
      In answer to your length of the keys array of a hash question, just use (keys %hash) in a scalar context, or (keys %hash).length.

      Wouldn't it be nicer if you could do
      %hash.keys.length
      ..or would that be too much sens^H^H^H^H like Ruby?
      --
      bp
    3. Re:perl6 is not a mistake by Anonymous Coward · · Score: 0

      Stop feeding the trolls you fucking idiot! I mean seriously, do you morons have to feed the trolls in every fucking story about Perl dragging the whole damn thread completely off-topic? Read this thread and then this one. Read the entire threads. Yes, all of them. Are you fucking proud of yourself now, you God damn imbecile? "Look, mom, I fed the troll on Slashdot!" You are just pathetic. Pathetic!

    4. Re:perl6 is not a mistake by autrijus · · Score: 1

      %hash.keys of course works, in the Rubyish fashion. It does work in Pugs now, too. :)

    5. Re:perl6 is not a mistake by Anonymous Coward · · Score: 0

      Excellent!

  10. perl patterns can match context sensitive grammars by sleepingsquirrel · · Score: 1

    Well, at least some of them.

  11. From a Free Software Developer by Prien715 · · Score: 2, Insightful

    I created a small Win32 project in Perl for my previous job (which I still maintain on occasion) to help IT people manage groups of machines more effectively (by storing hardware/software/license key information in a central MySQL database using an extremely simple but powerful program. If anyone's interested, the project homepage is here).

    I tried to use freely available software to create my program, but I didn't want have to install Perl on all the machines. So, I used a IndigoStar's Perl2Exe to convert the script and some dependent .exes to a single stand-alone exe. I see that GHC has support for the same ability according to the article. I was curious what practical experience anyone had using it on the Win32 platform and how its feature set/compatibility compares to Perl2exe.

    --
    -- Political fascism requires a Fuhrer.
    1. Re:From a Free Software Developer by umgah · · Score: 1

      I tried out an evaluation version of Perl2Exe, and found that it worked nicely. However, since then I've switched to pp for converting scripts into executables. It's available under the Artistic License.

    2. Re:From a Free Software Developer by autrijus · · Score: 1

      Thanks for using PAR/pp. Incidentally, it is developed by the same person as Pugs. :-)

    3. Re:From a Free Software Developer by Prien715 · · Score: 1

      The link's broken, but I'll have to take a look at it once I have time. I've been developing with the full version, and while the code is still runable (and I test it) in script form, I rely on lots of perl2exe's abilities (like being able to bundle other files into the perl2exe executable). Thanks for the information though! I'll definitely check it out at some point.

      --
      -- Political fascism requires a Fuhrer.
    4. Re:From a Free Software Developer by autrijus · · Score: 1

      The canonical link for PAR, is http://par.perl.org/. And yes, our feature set is largely a superset over perl2exe and perlapp's.

    5. Re:From a Free Software Developer by umgah · · Score: 1

      Hehe...I didn't notice your username on the original post. Thanks for providing such a useful tool.

  12. It's amazing how productive Autrijus is by Anonymous Coward · · Score: 1, Interesting

    Autrijus has accomplished more for Perl6 in one month of development than the two dozen people working on Parrot did in the past 3 years. It certainly proves that one individual can be 100 times as productive as their peers in the programming field. The big difference appears to be that Autrijus actually has a plan and a logical design. I do find it puzzling that the initial Perl6 interpreter is not being written in Perl5, though. Obviously speed is not a concern at this stage - only correctness. One hundred times as many developers know Perl5 than do Haskell. But, who can complain - Autrijus gets results. Eventually he plans to recode the P6 interpreter in P6 anyway. At his current pace perhaps it will only be in a month or two.

    1. Re:It's amazing how productive Autrijus is by autrijus · · Score: 2, Insightful
      Thank-you for your kind words and support... I really appreciate it. However, there is a few point I'd like to clarify:
      • Pugs and Parrot complement each other. Pugs is a parser, evaluator and eventually compiler of the Perl 6 language, and Parrot is a virtual machine for a compiler to target. As they are totally different things, the time taken to implement them could probably not be directly measured or compared.
      • Haskell is an excellent language to implement parsers and compilers. If I were to use Perl 5 to implement Pugs, it would take much more time and result in far more lines of code, which would probably hinder people's help -- it takes only a few hours to learn Haskell in order to hack Pugs, so I do not consider a major entry barrier.
      • That said, Perl 6 will become a much more language to write parsers and compilers in, so the eventual rewrite in Perl 6 should be much easier than implementing it in Perl 5.
      • The Perl 6 interpreter will not be recoded in Perl 6 -- the compiler will. :-)
    2. Re:It's amazing how productive Autrijus is by Anonymous Coward · · Score: 0

      We all know that Pugs does not have to target Parrot bytecode at all in order to accomplish the goal of having a Perl6 compiler. There are much simpler and better back ends available - both JIT and non-jit: Java bytecode, CIL, libjit and LLVM come to mind.

    3. Re:It's amazing how productive Autrijus is by BlackSoul · · Score: 1
      The Perl 6 interpreter will not be recoded in Perl 6 -- the compiler will. :-)
      This is why I enjoy Perl so much! When you can compile a language, with a compiler written in said language, you have something great. :o)
      --
      Revolutionary Discontent
  13. tabs by cakoose · · Score: 1

    Tabs are not that bad; you just have to be more careful. If you can handle tabs consistently, then tabs are fine. (I happen to use spaces because I've gotten used to it, but spaces do have their disadvantages...)

  14. OO at its core? by sam_vilain · · Score: 1

    Well, I'm not sure that it's entirely accurate to say that Perl 6 has objects at its core. That is because the concept of "core" is itself only a loosely defined concept.

    The fact that the object system is defined in S12 shows that they are not exactly "core" to the language, but they are definitely deeply ingrained, and widely employed. And consistent. And inflectable. And flexible. And not conforming to rigid ideas about what they should be.

    Yes, this is the point where you should get worried. Some guy has just started rambling vaguely about benefits of a system that is still very much vapourware, and promises so much that you have to wonder how it will *ever* be implemented, let alone be implemented in such a fashion that we will ever get to the point where a single Perl command might end up as a single CPU cycle.

    What I've seen so far has led me to think that it might just be possible, so I have to satisfy my curiosity...

    --

  15. Length is gone by Pan+T.+Hose · · Score: 0, Informative

    In answer to your length of the keys array of a hash question, just use (keys %hash) in a scalar context, or (keys %hash).length.

    Wouldn't it be nicer if you could do %hash.keys.length ..or would that be too much sens^H^H^H^H like Ruby?

    As Larry said in Apocalypse 12, "The length() function is gone" because "[it] has been deemed to be an insufficiently specified concept, because it doesn't specify the units."

    In other words, is $x.length the length of $x in characters and @x.length the number of elements in @x? What if $x is an array reference? What if we want to know the number of characters in @x, as is often useful when the array in question is the output of other program, or stdin? We could use a hyper version of the length method or junctions, or map, or loop, or...

    But simple things should be easy, and the length method would be ambiguous. So there is no %hash.keys.length in Perl 6. There is %hash.keys.chars and %hash.keys.elems, or just %hash.elems. The references to container data types are automatically dereferenced, so $hashref.elems does what you need without the need to explicitly dereference anything.

    Summarising, the correct version of (keys %hash).length in grandparent post should be %hash.elems and (keys $hash{"key"}).length should be %hash{"key"}.elems which seems quite straightforward if you ask me.

    If it makes too much sense then you certainly shouldn't read the rest of Apocalypses, Exegeses and Synopses. You have been warned.

    --
    Sincerely,
    Pan Tarhei Hosé, PhD.
    "Homo sum et cogito ergo odi profanum vulgus et libido."