[deleted]
Why I’m Learning Perl 6
221–230 of 380 posts
Re: Why I’m Learning Perl 6
#222> 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.
Re: Why I’m Learning Perl 6
#223Earlier quoted context omitted.
> Every major language, or at least the ones that matter for backend development, has support for thread multiplexing / coroutines / fibers, whatever. M:N threading is not, from a developer perspective, the same thing as coroutines/fibers. Coroutines are lower-level; it's possible to build something like M:N threading on top of coroutines, but it means doing a lot of work that's already done for you in a language tha…
> Coroutines are lower-level [than M:N threading] Not sure I understand what you're trying to say here, this sounds exactly backwards to my reading. A green threading library can be written in assembly language with no reference to anything but the hardware ISA specification and the ABI that defines the relevant calling convention. It's as "low level" as a software construct can be. The only lower level implementatio…
> Not sure I understand what you're trying to say here
The exact sense of the phrase you excerpted is explained in the next clause of the same sentence of the comment.
Re: Why I’m Learning Perl 6
#224why is everybody saying they are put off by Go? Did we pass the "trend" phase and now it's cool to say go sucks?
It doesn't suck, but personally I prefer languages that offer more abstractions than less, because I like writing less code. And I prefer exceptions to having to explicitly handle very potential error.
Go to me feels like Java did back in the 90s (in the sense that Java only offered some of the power of a language like Smalltalk while making you jump through hoops, and thus having to write more boiler plate).
Re: Why I’m Learning Perl 6
#225For some reason, when I started my software engineering career I got it into my head that I needed to learn as much as I could about programming languages. I learned ruby, perl5, python, lisp, forth, ml, ocaml, scheme, haskell, r, c#, java, lua, c++, factor, idris, asm, erlang, prolog, rust, d. But that wasn't quite enough because haskell and idris kept on talking about complicated type theory stuff. So I also learne…
That's understandable; if you look at the slides and see all of the integrated features in one big blast, you're going to think "holy moly this was not meant for mortal men".
In a way that's correct, because ultimately Perl6 is designed as the ultimate "kitchen sink" language; it has all the little features you could think of already baked in, which will include a lot of features you won't use.
The main reason for this stems from the overarching design philosophy; "There is more than one way to do something". The language ultimately tries to be as flexible as possible, going so far as to support modification the the core grammar, the object system, etc.
This is meant to make the developer as comfortable as possible, but it can lead the common case of perl-itis, also known as "write-once, read-nonce" code.
Re: Why I’m Learning Perl 6
#226I 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…
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 implementation of Perl 6 that run on MoarVM) is implemented in NQP, and started out on Parrot through an implemention of NQP for Parrot.
NQP[1] stands for Not Quite Perl, and shares various features with Perl, but is much more constrained in features as capabilities, making it easier to implement in a VM.
Because it's mostly implemented in NQP, it's fairly easy to port to a new VM, as all you have to do is get NQP running on that VM, and Perl 6 is mostly ported. For example, this is how the Java port happened within a few months of announcement. NQP was implemented, and then 95% of Perl 6 was already working.
When a new VM instead of Parrot was desired, MoarVM was conceived of as a VM to natively run NQP (rather than NQP on top of the native VM bytecode). Porting Rakudo to it was relatively easy, since Rakudo targets NQP, not a specific VM.
Pugs, conversely, was an interpreter/VM for Perl back in the days of Parrot, and ran its own Perl 6 implementation directly (no intermediary language, and it wasn't Rakudo). It was writtem in Haskell.
Niecza was another direct implementation of Perl 6, but implemented in C# for .Net. I don't believe it used NQP.
Re: Why I’m Learning Perl 6
#227Earlier 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…
You shouldn't look at it just in terms of how well it can utilize system resources. It allows for language level concurrent programming support which facilitates different programming styles. Some people find this style of programming 'fits' them and are attracted to these languages as a medium for expression.
So while other languages can use threads and async-IO perfectly well to keep all a systems resources utilized, that is not the only point of a programming language. Programming languages are primarily a means of communication.
Re: Why I’m Learning Perl 6
#228Earlier 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…
>> 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") thre…
You can call Thread.yield() at any time.
They are preemptive, and many things you do which will block effectively call Thread.yield() to give other things a chance to run.
I once wrote some code which took my 4 core CPU to about 500% utilization, and it was very simple code. (on a hyperthreaded Core I7) It was purposefully written to be fairly daft, as there were plenty of better ways to write it. I just wanted to see what would happen, and how long it would take to complete.
Re: Why I’m Learning Perl 6
#229> 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…
Nonsense: Solaris has had that thread multiplexing for over 15 years, for one counterexample.
Re: Why I’m Learning Perl 6
#230Perl is pretty much dead, I don't anyone still using that beside legacy code.
not true. There is still a lot of new Perl 5 code being written. Most of it is likely not very high profile, but it is still used a lot.