Hacker News new | ask | show | jobs
by Estragon 4151 days ago
Why would I learn this rather than Haskell?
4 comments

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

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

> lack of static typing

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

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

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

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

That looks like strict nominal run-time type checking to me, not static typing.
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

Why not learn both? Realistically speaking, though, it might be easier to land a job with Haskell than with Perl 6.
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 :-)