Perl is pretty much dead, I don't anyone still using that beside legacy code.
Nobody's using P6 for legacy code.
What kind of sane person who would use Perl ( 6 or older ) on a new project nowdays.
Why I’m Learning Perl 6
161–170 of 380 posts
Re: Why I’m Learning Perl 6
#162I like writing bash scripts a lot and perl is a natural step-up with powerful libraries to use. As others have said, the major obstacle for me has been the lack of great literature.
For small tasks I enjoy aesthetics of small dedicated Unix tools (grep, sed, awk, cut, sort) working together much more.
Perl tries to be everything at once, still mysteriously lacking interactive REPL out of the box. Yes, Python is more heavyweight for scripting, but it pays in the long term with better maintenance and tooling for big scripts.
Re: Why I’m Learning Perl 6
#163Earlier quoted context omitted.
Not really - no :N (green threads/co-operative multitasking) needed here. It's one task that wants to use multiple real CPUs, instead of multiple tasks that want to use one CPU.
i.e. SIMD i.e. something like: @array = 1, 2 ... 1,000,000 ; @array>>++ ; where the `>>++` operation increments each of a million integers with the workload distributed across multiple real CPUs?
Yes, or perhaps more generally, any loop where the compiler/runtime can infer that each iteration of the loop is independent of the others, and so they could theoretically run on multiple cores.
It's SIMD, exactly as you say, but potentially on much larger blocks of code than single arithmetic operations. A compiler that can pick where to use SIMD is doing the same kind of analysis. The difficulty in doing it at compile time is knowing whether or not it will be worth the cost.
In your example, the compiler could see that the array has a million entries and so spreading the work across threads might be a win. But in general, the compiler probably can't tell roughly how many iterations a loop is going to have, so it doesn't know where to thread and where not to.
Re: Why I’m Learning Perl 6
#164Earlier quoted context omitted.
cacciatore is a style of rustic stew in Italian cooking.
I would have bet that cacciatore was about food. To be pedantic, that's "alla cacciatora" but I won't be picky with Italian food terms outside Italy, it's good advertising anyway (I'm an Italian in Italy.)
> To be pedantic, that's "alla cacciatora" but I won't be picky with Italian food terms outside Italy
It's good that you won't be picky, since you're arguing against decades of "cacciatore" for Italian Americans. ;)
Re: Why I’m Learning Perl 6
#165Best argument to use Perl 6 is that it's fun. Like really fun. Whatever language you are using is boring. Perl 6 is just damn fun. It's like your favorite language but with dollar signs, and funner.
Re: Why I’m Learning Perl 6
#166Re: Why I’m Learning Perl 6
#167Can Perl6 merge all of its generated VM code into one "package"? One of my favourite things about Go is that you can statically compile everything and then deployment basically becomes scp.
I find it somewhat humorous that more than 25 years on, we are effectively reverting to static linking and bundling [1]. Way ... way back in the day, the argument was it would save memory, encourage reuse, etc. While some of this may have been true, it also gave rise to dynamic library hell. Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends. This would m…
> Reuse was overshadowed by incompatible versions, or API changes between versions that became the stuff of legends.
The Perl community has spent a couple decades "enjoying" taking (or being forced to take) a long hard look at that.
One result in P6 is :auth (authority), :api (api version) and :ver (package version) qualifiers, eg:
use Some::Module:ver:api;
Aiui this aspect of the language and tooling needs work but shows promise.
Re: Why I’m Learning Perl 6
#168I'm glad Perl6 finally went the route of MoarVM. I always felt that ParrotVM (which was supposed to also run Python and Ruby) was a terrible distraction and scope creep. The idea was laudable but it would have required buy-in from the other communities. As much as I like Perl, I don't think that would have been fair to them, as Python and Ruby have evolved into their own respective identities.
> The idea was laudable but it would have required buy-in from the other communities But imagine how cool it would have been - write a class in Python, sub-class it from Ruby, use that subclass in a function written in Perl, call that function from Lua code... Okay, I see it now. It was just too awesome for its time. Maybe in a hundred years or so...
[deleted]
Re: Why I’m Learning Perl 6
#169Earlier quoted context omitted.
Not really - no :N (green threads/co-operative multitasking) needed here. It's one task that wants to use multiple real CPUs, instead of multiple tasks that want to use one CPU.
I was referring two your second paragraph but had missed your reference to the OP, which makes it obvious what you are trying to say.
Sorry if I wasn't very clear. I'm kind of arguing against one side of M:N language automation, and for the other side of it.
Re: Why I’m Learning Perl 6
#170Earlier 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…
> So, how exactly these different ways of getting sub arguments are useful? Because in the second (add2), you might do something interesting with the second (or third) arguments depending on the first. You might have optional arguments. Your arguments might be a list of items you don't know the size of. It allows you to develop what you need out of the extensible core mechanism. Modules can and have built on that. >…
I cannot imagine any way of practical (ab)using this flexibility that could not be covered in Python with its only way of handling arguments.