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

181–190 of 380 posts

Re: Why I’m Learning Perl 6

#181

Post by Rjevski »

IslaDeEncanta wrote: post #74
Rjevski wrote: post #28

My personal issue with Perl is how much of a mess the syntax is (10 different ways of doing the same thing), and the lack of a standard library (CPAN is not a viable replacement).

Why is CPAN not a viable replacement? It has always been perfectly viable for me.

CPAN packages are written by thousands of different people with varying styles (cf. the issue with 10 different ways of doing the same thing), quality standards and maintenance schedules.

In Python I can expect the standard library to be consistent and be maintained as part of the core language. Now I don't mean that everything has to be in the standard library (I'm fine with the database access libraries being third-party for example), but in Perl even the most basic stuff like exceptions is only on CPAN and there are again multiple packages to choose from..

Re: Why I’m Learning Perl 6

#183

Post by felixgallo »

joosters wrote: post #175
kbenson wrote: post #127

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. That combining is what M:N threading is. Green threads are application level threads. "threads" are OS level threads. M:N threading is the ability to take M application level ("green") thread…

My point is that 'green threads/application level threading' is, IMO, not very useful in a language. As you say, it's the bit where putting them on actual threads is a win. A language that does its own green threads or co-operative multitasking is trying to do the kernel's job, and it will never be as good. It's at the purported 'web scale' in the article (I'm guessing this means lots of tasks, or lots of work) that…

it turns out that IO can dominate. When this happens, having green threads helps, because CPUs that would otherwise pend on IO availability will instead be freed to work on other tasks.

Re: Why I’m Learning Perl 6

#184

Post by qbaqbaqba »

bjd2385 wrote: post #67
forinti wrote: post #38

Earlier quoted context omitted.

Perl 6 still has to overcome Perl 5, which is everywhere and is a great language. I never get around to using Perl 6 because 5 is already there in every Linux distribution.

I wish Linux distros shipped with more recent language versions, e.g. Python 3.6 and Perl 6 in addition to just 3.4/5 and 5. I understand that it's not their job to try and push people to update their language skills, but it'd be nice to have access to them right off the bat if they feel like it.

Red Hat 7.3 ships perl 5.16.3 - it's from 2013. 6.9 ships perl 5.10.1 from 2009.

Re: Why I’m Learning Perl 6

#185

Post by krylon »

seagreen wrote: post #180
krylon wrote: post #136

Earlier quoted context omitted.

FWIW, I, too, have tried learning Haskell and ended up banging my head against the wall over and over. With Lisp, I eventually "got it", but Haskell has evaded my attempts at understanding it with impressive stubbornness[1]. Disclaimer: I do not hate Haskell, I just don't "get it". If you love the language, fine, have as much fun with it as you possibly can. I for one have given up, at least for now. Maybe I'll try a…

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.

Re: Why I’m Learning Perl 6

#187

Post by yorwba »

gjm11 wrote: post #143
bloobloobloo wrote: post #133

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.

I'm not sure I understand your exercise. What do you mean by "Python's quoting documentation", and what do you mean by "editing" it?

I was wondering about that, too. Unless `"Python's quoting documentation"` is an easter-egg in "help()" that recursively contains a quoted version of itself, it should be possible to just escape all problematic characters. But maybe that counts as `"editing"`? Not sure.

Re: Why I’m Learning Perl 6

#188

Post by rlpb »

sherr wrote: post #49
rlpb wrote: post #39

Earlier quoted context omitted.

...and then deployment basically becomes scp. And security updates for your deployment become...what?

Rebuild and scp the whole lot again? Not necessarily a big deal.

Rebuilding by pulling in all your dependencies from the Internet again? That's not something I want to do when the clock is ticking to get a security update out. What if some random third party dependency is hosted somewhere that is down, or has been pulled?

And how do I know I have to rebuild in the first place?

You'll probably tell me that there are tools to help deal with this. I'm sure there are. My point is that it isn't as simple as "scp".

Re: Why I’m Learning Perl 6

#190

Post by rurban »

oconnor663 wrote: post #59
rurban wrote: post #10

Earlier quoted context omitted.

GIL less yes, but not lockless. The previous perl6 VM, parrot, had lockless threads, scaling linearly per native core. MoarVM even needs to lock on hash or array accesses, which is certainly not state of the art.

How did parrot write arrays from multiple threads without a lock somewhere in there?

You deferred updates to the owner via scheduler, with high prio, and continue. parrot threads are lock free but not wait free. The NQP compiler needed to know about threaded writes and schedule the update, with a semaphore, while the other threads continue.

What MoarVM got better was everything else. The GC, the calling convention, the OO (6model), the jit. I was on my way to fix all the parrot damage done from the previous decade, because this would have enabled all architectures and proper threading for perl6, but then perl6 decided to kill it and go with Moar. And spread a lot of lies on threads.

Post reply on HN