Live data from Hacker News

Why I’m Learning Perl 6

evanmiller.org

191–200 of 380 posts

Re: Why I’m Learning Perl 6

#191

Earlier quoted context omitted.

I don't understand how some other language would not need to handle all the errors ? I have written code in go/java/php/python/js and error handling has been a majority chunk of lines in most if not all cases(in other cases the errors are just not handled). The best ideal case flow is always easiest to build.

I highly recommend that you try out a language with good support for option/maybe types: Haskell and Rust are good options here. Very often, your error handling through a chain of operations will be to use a slightly different operator (say '?.' Instead of '.') and any errors will be automatically propagated to the end of that section of code where you can handle them all in one place. Alternatively, give Erlang or E…

> I highly recommend that you try out a language with good support for option/maybe types

Right. Like Perl 6.

> Very often, your error handling through a chain of operations will be to use a slightly different operator (say '?.' Instead of '.') and any errors will be automatically propagated to the end of that section of code where you can handle them all in one place.

P6 does this stuff particularly well.

It makes option types opt out. You have to explicitly specify the equivalents of Just or None, otherwise you're automatically dealing with an option type if you're dealing with a type.

Conditional constructs are designed to work well in this context.

One can use ML style pattern matching as those conditional constructs.

And other styles of matching.

Error exceptions are unified with error values, allowing codebase/author A to use one style, and B to use the other but pretend that A's code used B's style, and for C to use B's code in whichever style they prefer, seamlessly promoting/demoting between warnings, errors, and exceptions, including across language boundaries, as fits a use case.

And so on. Perl 6 learned from Perl 5 but it also learned from Haskell and many other languages.

> Alternatively, give Erlang or Elixir a shot

Note that the author of the OP is well known in the Erlang community.

Re: Why I’m Learning Perl 6

#192
post #73

Earlier quoted context omitted.

I looked quickly through the slides and saw that perl has now grammar build in the language... Truly an interesting feature

Is the language itself a good place for parsing/grammar handling? I could not even find in the standard documentation which kind of parsers it supports, is it LR(k)? LL(k)? Any CFG? What parsing method does it use: recursive descent, shift-reduce, something more general like CYK/Earley algorithms? How does it handle ambiguities? It turns out that `grammar` keyword generates recursive descent parsers and anything even…

perl6 grammars have to be seen in context of perl5 regexp.

Basically, regular expressions have grown to impossible to understand, write and modify. Mostly due to perl.

Yet, they are used daily by millions of developers, because they are a ton better than manual character checks.

Perl6 grammars are basically an attempt to bring developers another step forward.

Re: Why I’m Learning Perl 6

#193
post #18

Can anyone recommend a good book on Perl 6? Are there any (even bad ones)? Right now I feel the major reason that keeps me from investing time in Perl 6 - besides adoption by distros - is the lack of a good book, like the Lama and the Camel book for Perl 5. It's kind of frustrating after having waited so long.

> adoption by distros

This has improved, and I think most distros now ship Rakudo (Perl6 on MoarVM). At least: Debian, Ubuntu, Fedora, and Arch do.

Re: Why I’m Learning Perl 6

#194
post #65

I hate perl6. I hate it because I tried to get involved in the project early on, and it led me down the Haskell rathole. I don't know what Haskell looks like today, but a decade or more ago it was the hardest language to pick up that I had ever experienced. It was as if I had a solid background in latin languages and I was trying to pick up Chinese based on a handful of tutorials written by a tourist on the back of a…

The Haskell introductory landscape has definitely changed.

Learn You A Haskell for great good (http://learnyouahaskell.com) is an excellent introductory book to read to get started with Haskell.

A drier but more in-depth read is http://book.realworldhaskell.org/

Also, when you hit monads again, the best advice I can give you to understanding them (99% of Haskell guides out there seem to be about monads) is to take this path:

Functors -> Applicatives -> Monads

And check out this link: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

I'm not sure those resources were around when last you tried haskell, but they're worth giving a read.

Haskell has M:N threading, and a strictness about types and semantics that's very refreshing to me. Yes, I could have written my most recent web project in some other language that would have been quicker (because it would have been simpler and likely more imperative), but I trust my codebase so much more with Haskell. Ironically it's my own understanding and clarity of thinking that I sometimes doubt now, but that's a good problem as far as I'm concerned, makes me think clearer.

[EDIT] - Can't believe I forgot, but Erik Meijer's series on Haskell is actually one of the first resources that actually got me really into it, it is absolutely fantastic, I actually watched the whole series before I read learn you a Haskell.

https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun...

Re: Why I’m Learning Perl 6

#195
post #185

Earlier quoted context omitted.

Haskell's rough to learn because it hits you with purity, category theory inspired typeclasses, and laziness all at once. It's natural that people struggle with this (I sure did). If you feel like trying a pure language again someday you could consider PureScript (which just has the first 2 things above) or Elm (which just has the 1st). If you do try I'd like to hear how it goes, email in profile.

My main problem with Haskell was not the pure, funcational part. It was the side-effect-laden part. If I were ever to go there again, I would probably give OCaml a try. It seems to offer many of the benefits of Haskell, while also offering "a way out" into the familiar world of objects and side effects. But don't hold your breath, I don't think I will get there this year.

What do you mean by the "side-effect-laden" part? Did you find yourself writing lots of side effecting code because of Haskell (which seems weird)? Or Haskell just wasn't a good fit for a project that was full of side-effecting code?

If it's the latter, I can definitely tell you that part of the zen of Haskell is firming up the boundaries between side-effecting code and pure code -- for example, IMHO the better you get at Haskell, the less `do` statements show up in your code (for better or for worse, because >>=, , and co make it harder for newcomers to enter a codebase)

Re: Why I’m Learning Perl 6

#196

Earlier quoted context omitted.

> 10 different ways of doing the same thing Mostly an urban myth. Where it isn't, at least 8 of those ways are actually important. Exercise: write a python program that prints Python's quoting documentation, without external files, without editing the documentation. Spoiler alert: it's impossible.

So, how exactly these different ways of getting sub arguments are useful? sub add1 { my ($arg1, $arg2) = @_; $arg1 + $arg2; } sub add2 { my $arg1 = shift; # possibly two screens of dense code here, then my $arg2 = shift; $arg1 + $arg2; } sub add3 { $_[0] + $_[1] } # There may be some other ways to extract arguments # that I am not aware of. # It's possible to combine any of the methods! And this is just argument acce…

You aren't really showing off different ways to get arguments in any of those examples. In all of them, you get the arguments in a list called @_; you're just showing off three different ways to get values out of a list, which Python has plenty of ways to do as well. Translating your examples into Python:

    def add1(*_):
        _ = list(_)

        arg1, arg2 = _
        return arg1 + arg2

    def add2(*_):
        _ = list(_)

        arg1 = _.pop(0)
        arg2 = _.pop(0)
        return arg1 + arg2

    def add3(*_):
        _ = list(_)

        return _[0] + _[1]

Re: Why I’m Learning Perl 6

#197
post #196

Earlier quoted context omitted.

So, how exactly these different ways of getting sub arguments are useful? sub add1 { my ($arg1, $arg2) = @_; $arg1 + $arg2; } sub add2 { my $arg1 = shift; # possibly two screens of dense code here, then my $arg2 = shift; $arg1 + $arg2; } sub add3 { $_[0] + $_[1] } # There may be some other ways to extract arguments # that I am not aware of. # It's possible to combine any of the methods! And this is just argument acce…

You aren't really showing off different ways to get arguments in any of those examples. In all of them, you get the arguments in a list called @_; you're just showing off three different ways to get values out of a list, which Python has plenty of ways to do as well. Translating your examples into Python: def add1(*_): _ = list(_) arg1, arg2 = _ return arg1 + arg2 def add2(*_): _ = list(_) arg1 = _.pop(0) arg2 = _.po…

That does not change the fact that in Python everybody writes

    def add(x, y):
       return x + y
whereas the Perl codebase that I work with has every possible combination of these methods.

Re: Why I’m Learning Perl 6

#198

Earlier quoted context omitted.

For Python there is no native support for threads because of GIL. You can get around this through multiprocessing etc but these are hacks

There is native support for threads, it's just that they don't run concurrently.

They do run in parallel, so long as all but one are running low-level library code which has released the GIL, but you can't call back into the runtime without grabbing the GIL.

Re: Why I’m Learning Perl 6

#199
It's pretty cool to see Perl adding this feature. My rubric for the three big scripting languages (once upon a time?) was:

Perl: Good at regular expressions, and proper per-processor core threading, Bad because what you wrote will be indecipherable to future you

Python: Very expressive (without being too much), lots of library support, good drop-to-c/do-stuff-fast support, sensible support for object and functional programming paradigms that evolved over time, super useful stdlib. Bad because GIL

Ruby: ???? at least it's beautiful? seems to only be used in codebases that are rails-based which is basically a red flag for me now due to personal preference

It looks like Perl just got another killer feature

Re: Why I’m Learning Perl 6

#200
post #196

Earlier quoted context omitted.

You aren't really showing off different ways to get arguments in any of those examples. In all of them, you get the arguments in a list called @_; you're just showing off three different ways to get values out of a list, which Python has plenty of ways to do as well. Translating your examples into Python: def add1(*_): _ = list(_) arg1, arg2 = _ return arg1 + arg2 def add2(*_): _ = list(_) arg1 = _.pop(0) arg2 = _.po…

That does not change the fact that in Python everybody writes def add(x, y): return x + y whereas the Perl codebase that I work with has every possible combination of these methods.

But people using Python do at different times use destructuring, pop, and indexing to get values out of a list, which are the different ways of doing the same thing that you demonstrated.

e: Just clarifying that your complaint here is that every sub in Perl 5 just receives a list of its arguments; this isn't a "more than one way to do it" issue.

Post reply on HN