Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m Learning Perl 6

evanmiller.org

Post reply on HN
Print view View original

251–260 of 380 posts

Re: Why I’m Learning Perl 6

#251

Post by jxramos »

16bytes wrote: post #245

Even though this could more properly be called, "Why having language support for M:N thread multiplexing is important", I thought it was a refreshing article on why I might actually use a bit of perl6. Last year I attended a conference and saw Larry Wall speak. It was an overview of Perl 6 and I was completely underwhelmed. Larry spent about half the time talking about unicode support. It wasn't a boring talk, but I…

I had saw an old coworker at a Python meetup group session the other week and I started to remember he and others had to support all these Perl scripts. Since leaving that place and seeing so much of Python everywhere I thought the other day where Perl wound up in the mix of things several years later. Seems like the community kept going.

Re: Why I’m Learning Perl 6

#252

Post by cygx »

kbenson wrote: post #226
throwaway7645 wrote: post #209

Earlier quoted context omitted.

Perl6 is no longer implemented in Haskell on the backend. I think the old parrot VM was, but MoarVM is in C. On the bright side, a lot of cool FP concepts made it into P6 as a result of the original Haskell backend, so useful cross polination happened. Even better, you can do FP stuff in a much easier to understand way and you can also mix in OO when needed or relevant.

> Perl6 is no longer implemented in Haskell on the backend. I think the old parrot VM was Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC (parrot byte code). Rakudo Perl 6 developers took the route of developing Perl 6 through an intermediary language NQP, which is a language aimed at making it easy to implement interpreted languages. Rakudo (the im…

Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC

PBC was the bytecode format, the human readable low-level syntax was called PASM and the slightly higher-level synax was called PIR.

Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winxed.

Re: Why I’m Learning Perl 6

#253

Post by jabl »

hardwaresofton wrote: post #194
Steeeve wrote: 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…

I'm learning myself some Haskell (so I'm far from an expert, so take this with a grain of salt...), but AFAIK the current recommended introductory resources are described here: https://github.com/bitemyapp/learnhaskell

tl;dr: 1) If you want to buy a book, http://haskellbook.com/ is supposed to be good

2) If you instead want to learn from free online sources, a) cis194 spring 2013 followed by b) The data61 course (links in the github link above).

Re: Why I’m Learning Perl 6

#254

Post by chrisseaton »

Rafert wrote: post #222
StevePerkins wrote: post #22

> Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE CODE, where application threads aren’t pinned to pthreads) your options today are precisely Erlang, Go, .NET, and Perl 6. Putting aside the "web scale" jokes ( http://www.mongodb-is-web-scale.com/ ), this statement is still absurd. Every major language, or at least the ones that matter for backend development, has support for thread multipl…

> Ruby has [...] likewise community gems with more robust functionality like Quasar. https://github.com/ruby-concurrency/concurrent-ruby for those wondering. Rails uses it as of version 5.

You must be thinking of something else. Concurrent Ruby doesn't include any functionality that is anything like fibres, lightweight threads, or M:N threading (I work on the project).

Re: Why I’m Learning Perl 6

#256

Post by anonacct37 »

RX14 wrote: post #92
StevePerkins wrote: post #22

> Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE CODE, where application threads aren’t pinned to pthreads) your options today are precisely Erlang, Go, .NET, and Perl 6. Putting aside the "web scale" jokes ( http://www.mongodb-is-web-scale.com/ ), this statement is still absurd. Every major language, or at least the ones that matter for backend development, has support for thread multipl…

Unfortunately, unless the IO in the stdlib uses or is modified to schedule these fibers around evented IO, they're essentially useless as soon as you use an external library. Go and Erlang do this, Crystal does this but with only N:1 multiplexing (but that will change before 1.0), but I don't know about other languages.

Very true. Node does this too, in the sense that all node libraries are async/callback aware or have async/callback versions of those.

I much prefer the go/erlang version of this. Playing the "what color is your function" game or "will it block" is no fun.

Re: Why I’m Learning Perl 6

#257

Post by raiph »

dmytrish wrote: post #197
kbp wrote: 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.

Why does Python have other options if no one is using them? Are these other options cruft in the language design, the compiler, or just reasonable support for features intended for other, perhaps infrequent, usage?

The old P5 motto TIMTOWTDI was long ago updated to TIMTOWTDIBSCINABTE and P6 adopts the latter. While P6 supports most of the options shown for P5, most folk writing P6 will just write something like:

    sub add($x, $y) { $x + $y }

Re: Why I’m Learning Perl 6

#258

Post by kbenson »

cygx wrote: post #252
kbenson wrote: post #226

Earlier quoted context omitted.

> Perl6 is no longer implemented in Haskell on the backend. I think the old parrot VM was Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC (parrot byte code). Rakudo Perl 6 developers took the route of developing Perl 6 through an intermediary language NQP, which is a language aimed at making it easy to implement interpreted languages. Rakudo (the im…

Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC PBC was the bytecode format, the human readable low-level syntax was called PASM and the slightly higher-level synax was called PIR. Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winx…

Ah, I figured that part was slightly off (since I knew PBC was bytecode and thus my waffling with "bytecode syntaxes"), but really didn't want to research the history I had already forgotten. Thanks for the correction.

> Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winxed.

I vaguely remember NQP/NQP-rx etc as being branches with reimplementations or new features, but I could be way off. I remember Winxed, but I'm not sure I realized Whiteknight implemented it at the same layer as NQP instead of on top of it. That would explain why some other new language implementations started using it instead of NQP, which I recall (e.g. I think someone started up a new Ruby on Parrot implementation after Winxed that used Winxed). I miss reading Whiteknight's blog posts on massive changes he was working on.

Re: Why I’m Learning Perl 6

#259

Post by anonacct37 »

supremesaboteur wrote: post #47
rootlocus wrote: post #37

Earlier quoted context omitted.

I'd like to know why people are downvoting this.

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

You might have chosen bad words, but people reading this should know this statement it false. Python has threads. You can create them and (if you're using linux) see them in the /proc filesystem.

A more accurate statement is: "python bytecode can't execute concurrently w/o something like multiprocessing". The key difference? You can do multithreaded I/O all day long, which is a pretty important use case of threading. You can also hand off work to C and release the GIL, although this isn't as common. Example: XML parsing, regex, numeric work.

FWIW all these gotchas are one of the reasons I love just having complete threading support built in to my language.

Re: Why I’m Learning Perl 6

#260

Post by jabl »

joosters wrote: post #126
le-mark wrote: post #107

Earlier quoted context omitted.

> For long-running tasks, if they are I/O bound you can use non-blocking I/O and event loops. If they are CPU bound, then use threads or separate processes. The two techniques can be combined to scale well across multiple cores. One might suppose this to be the case, but to my knowledge only network IO is truly non blocking, although there are async io api's in some languages for disk reads/writes, they're still bloc…

Yeah, non-blocking disk I/O is painful. I've never had to write code that did enough disk reading/writing to try to parallelise it, so I've never researched the solutions that much. What I don't understand is why disk I/O should require a different API to be non-blocking. After all, network I/O can be blocking or non-blocking with the same read() and write() calls that disk I/O uses. There must be some reason why no…

The short version is that disk I/O is integrated with the page cache with all that entails, and allows things like seeking.

To an extent this is a design rooted in a world where disks are much faster than network access. But perhaps that world is coming back with SSD's/NVME/etc..

Post reply on HN