HN user
I'm pretty sure that the "expression-lambdas" were inspired by Haskell, where you get a lambda simply by writing an operator with one or more missing operands.
In Perl 6, detecting that an operand is "missing" isn't possible due to the existence of prefix/infix/postfix operators with the same names, so it expects a "whatever" star in place of the missing operand... :)
Come on now, it's clear that he meant to compare CPAN to the corresponding module repositories of those other languages.
That looks like strict nominal run-time type checking to me, not static typing.
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.
Is the worst thing you can say about Python that it forces you to indent your code?
That's an unduly simplistic argument. "Indentation that looks clean" and "Indentation that fulfils Python's specific needs" are not the same: one is a superset of the other. This means that enforcing the latter is in fact an extra burden and a loss flexibility. Whether the burden is less than having to write braces all the time comes down to personal taste, but to pretend that it does not exist is dishonest.
In any case I could get used to the significant indentation. What actually repels me the most from Python is the lack of non-broken lexical scoping, which - together with the "only one expression per lambda" limitation - makes closure based programming solutions awkward and hard to get right in Python. Which is unfortunate because I personally really like those kinds of solutions...
The ironic thing is, that this situation leads many Python programmers to believe that closures are inherently complicated/difficult/bug-prone, and sneer at languages which promote them heavily as "not newbie friendly".
To get back on the thread's topic, Perl 6 is one of those languages where function and variable handling is built on proper lexical scoping, and closures are everywhere. Even regexes are closures, in the sense that they are treated as first-class code objects (that just happen to be written in a different syntax), and if a regex uses variables from other Perl 6 scopes it closes over them.
Maybe I'm the only one who feels that way, but that kind of thing excites me in a way that Python never could.
But to each their own!
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, *+* ... *;
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.
Late for what, exactly?
Do people no longer write code? Because if they do, some of them might might choose to use Perl 6 for that, and that's all the success a programming language can hope for.
I see no reason why Perl 6 can't find its niche among people who prefer the Perlish over the Pythonic way to approach problems, but want a modern, consistent, cruft-free language (which Perl 5 is not).