I'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.
Why I’m Learning Perl 6
131–140 of 380 posts
Re: Why I’m Learning Perl 6
#132Maybe it's because I'm old, but I don't see the appeal of M:N multiplexing in a programming language (i.e. 'green threads' or some other user-level context switching) 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. The OS is designed to sche…
> 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…
I'm not an expert, but I think you're right for POSIX.
Windows does apparently offer the necessary building blocks; this is the most relevant HN sub-discussion: https://news.ycombinator.com/item?id=9584269
Re: Why I’m Learning Perl 6
#133My 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).
> 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.
Re: Why I’m Learning Perl 6
#134Earlier quoted context omitted.
I agree that they can be too heavyweight for short-lived work. e.g. a program needs to sort a small(ish) amount of data, it would be great if the language could make the sort utilise all the available cores on the machine, without the base program needing to do any kind of multi-process or multi-threading. Spinning up threads to do this kind of thing could be too slow to be of any benefit, but you could use thread po…
You just described M:N threading, and what's being touted in this article as good about Perl 6.
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.
Re: Why I’m Learning Perl 6
#135> 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…
> 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…
That's kind of the problem when the author uses meaningless words like "WEB SCALE", we don't really know what it means exactly.
If it's about serving a great number of concurrent connections, I'm not sure why M:N is the only way to go.
Re: Why I’m Learning Perl 6
#136I 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…
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 again next year.
[1] NB that the word "stubbornness" has three pairs of double consonants. How fun is that?
Re: Why I’m Learning Perl 6
#137> Why is this important? 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. I guess the author doesn't know about Haskell? The concurrency story for Haskell is great, and using the right library, you can literally just define types for the routes for your backend and then…
Does Haskell have thread multiplexing?
Yes, as well as excellent abstractions for putting those threads to work. See [parallel](https://hackage.haskell.org/package/parallel), [async](https://hackage.haskell.org/package/async), and [monad-par](https://hackage.haskell.org/package/monad-par) for a few examples. If you just need a web server [Warp](https://hackage.haskell.org/package/warp) is extremely competitive.
Re: Why I’m Learning Perl 6
#138I'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...
Re: Why I’m Learning Perl 6
#139Earlier 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…
I'm not an expert, but I think you're right for POSIX. Windows does apparently offer the necessary building blocks; this is the most relevant HN sub-discussion: https://news.ycombinator.com/item?id=9584269
[deleted]
Re: Why I’m Learning Perl 6
#140Earlier quoted context omitted.
For me, other than the fact that I don't need yet another Algol reimplementation in my life, I'm also not interested in code littered with error handling. Also strongly prefer FP.
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 Elixir a shot: their primary mode of error handling is "don't, let it crash", which is possible due to the relatively unique process model.