[muraiki]

If you want to have an idea of what makes Perl 6 compelling, check these slides that were submitted a few days ago, "Perl 6 for Mere Mortals" (which is also another talk at FOSDEM): https://news.ycombinator.com/item?id=8953368

I hate to repeat a comment of mine, but for the sake of emphasizing just how different Perl 6 is, here's a version of Fibonacci in Perl 6:

  subset NonNegativeInt of Int where * >= 0;

  proto fib (|) is cached returns NonNegativeInt {*}
  multi fib (0) { 0 }
  multi fib (1) { 1 }
  multi fib (NonNegativeInt $n) { fib($n - 1) + fib($n - 2) }

  say fib(100)

Edit: Another good recent talk is "Adventures in Perl 6 Asynchrony," which shows off promise combinators, channels, and supplies: http://jnthn.net/papers/2014-yapceu-async.pdf

[wantarray]

The author of that snippet was probably just trying to demonstrate multi-method dispatch using a familiar example; I don't think that's how people would actually calculate Fibonacci numbers in Perl 6.

I expect most would either use plain 'ol imperative code if that's what they're used to (from Perl 5), or do it with the sequence construction operator (triple dot):

  my @fib := 0, 1, *+* ... *;

...which looks funky on first sight, but is really just another operator.

From what I've seen so far, Perl 6 code is still similar to Perl code. Presentation snippets tend to focus on specific new features and should not be taken as representative samples of real-life code.

[muraiki]

I wrote the above snippet, but it was basically just one step beyond what Curtis Ovid Poe shows in his "Perl 6 For Mere Mortals" presentation.

My intention wasn't to make people say "wow, I know Perl 5 but now I'll never figure out Perl 6," but rather to illustrate some new features in the context of a familiar example. :) In fact, the above-mentioned presentation introduces P6 features by gradually expanding upon P5 code, showing that you can gradually grow into the language.

[walterbell]

Thanks for the presentations. Have you seen any performance benchmarks? It would also be good to see Lua included in the language comparisons.

[muraiki]

I'm not sure about any current Perl6 vs other language benchmarks; older benchmarks aren't terribly useful because within the past year MoarVM both became the dominant P6 VM and also received substantial performance optimizations. My understanding is that this is one of the big goals of this year.

Another one of Johnathon's excellent presentations goes into depth about the kinds of optimizations being made in MoarVM: http://jnthn.net/papers/2014-yapceu-performance.pdf

[walterbell]

The new VM seems to be a good foundation, hopefully the Whipuptitude and Manipulexity can be made performant in high-use operations.

[brrt]

We try to :-). Specifically, there are designs underway to implement e.g. hyper operators - those things that apply an operator to an array of values, irrespective of order - by SIMD instructions on the hardware level. If you're interested you're very welcome to come and check it out.

[edit] - there is also some progress in speeding up list operations, because as it turns out making all lists lazy is not a really good way to do fast list computations. This is known as the 'Great List Refactor' (GLR) in perl6 circles, and spoken of with awe :-)

[walterbell]

Is there a mailing list where such things are discussed?

[brrt]

We don't really use a mailing list, but we do have an IRC channel on freenode: #moarvm. Although just as often MoarVM-specific issues are discussed on #perl6

[steveklabnik]

In his talk, Larry specifically said something like "Please understand that we may or may not be comparable to Perl5 in some benchmarks, and that speed is something we're working on. We'll get there, and it's good enough already for many tasks."

[Estragon]

Why would I learn this rather than Haskell?

[muraiki]

Oh, I'm a big fan of Haskell! It's definitely a language worth learning. However, if you want a pretty nice but still "dynamic feeling" (as opposed to Java-ish) object system, Perl 6 has you covered there. I'd look at P6 as similar to Scala in that it mixes both OO and FP ideas, but with P6 leaning more towards the OO side than the FP side, with not as much type safety as Haskell/Scala/OCaml but with more type safety than, say, Clojure.

If you're familiar with another OO dynamic language like Perl 5, Python, or Ruby, you can probably get up to speed more quickly in P6 than Haskell, and you can gradually introduce more advanced P6 ideas as your ability grows.

But yeah, I'd still recommend you learn Haskell... and Erlang, and Lisp... and...

[wantarray]

> Why would I learn this rather than Haskell?

You wouldn't.

That is to say: You might learn Haskell if you want do write 100% functional code, and Perl 6 if you want to write imperative/procedural/OO code with functional idioms mixed in here and there (in places where that facilitates a more elegant approach).

I.e. the two languages are not really competing in the same category.

Even though Perl 6 has first-class code objects, closure semantics, basic pattern-matching, lazy lists, immutable data types, and so on, a lot of the syntax and default behaviors are geared towards stateful programming styles, which - combined with the lack of static typing - means that strictly sticking to functional programming in Perl 6 will be awkward and you'd be better off using a dedicated functional language if that's what you want.

[raiph]

> lack of static typing

A key feature of Perl 6 is optional static nominal typing:

http://www.reddit.com/r/perl6/wiki/gradualtyping

[raiph]

A much better explanation that I could possibly give, hot off the press:

http://jnthn.net/papers/2015-fosdem-static-dynamic.pdf

[wantarray]

That looks like strict nominal run-time type checking to me, not static typing.

[raiph]

Thank you for replying.

    my Int $age = 40;

    $age = "old";

That will generate a compile-time error. (Because the "old" bit is a string literal which is interpreted in this case as being of nominal type Str which isn't compatible with the nominal type Int).

Do you have any tips for me on how to make it clearer on the page I linked that this is compile-time checking? Or, more simply, did you just not believe the "compile-time" comment on the page I linked or did you just miss it, perhaps because it's "commented out"? Would it make sense for me to incorporate some of what I write below?

----

Perl 6 supports more than just static nominal typing. You can add arbitrary constraints:

    my Int $school-age where 5..18 = 40;

The code that comes after the 'where' (the '5..18' bit) can be arbitrary code. It is tested against any value that would be assigned to the $school-age variable.

Most folk will just like the convenience of this construct and won't care whether it results in a check at compile-time or run-time.

But some will care.

So, while nominal typing is a compile-time checking affair, what about these arbitrary constraints? Do these result in checks at compile-time or run-time? Well, it depends.

Key quotes from the relevant language design doc[1] are:

> A where clause is considered static if it can be applied to the types to the left of it at compile time to produce a known finite set of values.

The line of code we're looking at:

    my Int $school-age where 5..18 = 40;

can clearly be reduced to the set of integers from 5 to 18. And the compiler code to successfully make that analysis is fairly straight-forward, so it could fairly easily be implemented in Rakudo today.

However, for 6.0.0 (by which I mean the suite of 35K+ tests that are supposedly going to reach beta status by September and the Rakudo compiler that is supposedly going to reach gold status by the end of the year) there's this:

> for 6.0.0 any structure type information inferable from the where clause will be ignored

In other words, the line we've been looking at with the `where` clause will result in a run-time check for 6.0.0.

----

[1] http://design.perl6.org/S12.html#Multiple_constraints

[kachnuv_ocasek]

Why not learn both? Realistically speaking, though, it might be easier to land a job with Haskell than with Perl 6.

[perlgeek]

Coming from other dynamic and mostly OO/imperative languages, Perl 6 is evolution, and Haskell is revolution.

If you think that you need a revolution to get to a desirable state, Haskell is for you. If you prefer not to have to re-wire your brain, give Perl 6 a shot.

Or, of course, do both :-)