Earlier quoted context omitted.
There's lots of literature out there for Perl 5 (like the so-called "Camel Book"). Perl 6 literature is pretty scarce, though.
There is 2 out now and many in development. So really not that bad.
Why I’m Learning Perl 6
261–270 of 380 posts
Re: Why I’m Learning Perl 6
#262Earlier quoted context omitted.
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.
HN doesn't support full Markdown. :(
I think you're thinking of CommonMark. That link format isn't valid in canonical Markdown either (just to some of the common variants that also went by "Markdown").
I was always partial to the variants that could do citations well. They would automatically link-ify items postfixed by [1] etc with the link included at the citation at the bottom. I implemented a customer facig newsletter system at one job using that, where it automatically made the emails multipart when markdown was submitted, with the text part being raw Markdown. When using citations, it's still very readable.
Re: Why I’m Learning Perl 6
#263Earlier quoted context omitted.
HN doesn't support full Markdown. :(
I think you're thinking of CommonMark. That link format isn't valid in canonical Markdown either (just to some of the common variants that also went by "Markdown"). I was always partial to the variants that could do citations well. They would automatically link-ify items postfixed by [1] etc with the link included at the citation at the bottom. I implemented a customer facig newsletter system at one job using that, w…
That's the way I format my bigger HN comments. Didn't know [this](wasn't) part of the Markdown standard, though. Thanks!
Re: Why I’m Learning Perl 6
#264Earlier quoted context omitted.
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.…
> A more accurate statement is: "python bytecode can't execute concurrently
No this isn't any more accurate. Python bytecode does execute concurrently if you have multiple threads. It just doesn't execute in parallel.
Re: Why I’m Learning Perl 6
#265Even 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…
Extending Evan's analogy, perhaps trying to explain the joke ruins the joke?
Re: Why I’m Learning Perl 6
#266Perl6 is indeed a very nice language that I've been watching for a few years. As soon as the performance beats Python and the stability is solid I'll probably switch over from Python...there's just a lot there.
I have seen examples where the naive Perl 6 implementation is faster than the equivalent C code. (The one I'm thinking of is probably owing to Spesh and the JIT, but I forget what it was about)
Here's an example where a naive Perl 6 version is going to beat the pants off of the naive version in another language:
Find the sum of all integers from 10 to 1000000 inclusive.
In Perl 6:
say [+] 10 .. 1000000
This finishes almost immediately. (It also does so if the endpoint is 10¹⁰⁰⁰ or more)
The reason is if you use the built in version of the &infix:«+» operator, it calls the sum method on the Range object. That particular method knows how to calculate the sum on the Range without iterating through the values. If you modify the &infix:«+» operator lexically it won't take that shortcut.
This also works the same if you wrote it like this:
say Range.new(10,1000000).reduce(&[+])
There are plenty of areas where Rakudo Perl 6 is slower than I would like, but for many uses it is fast enough.
Re: Why I’m Learning Perl 6
#267Earlier quoted context omitted.
M:N threads exist because the operating system threads are too expensive (despite decades of development, OS threads operated at the wrong abstraction layer). If operating system threads scaled reasonably well, there would be (virtually) no need for M:N threads.
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…
> it would be great if the language could make the sort utilise all the available cores on the machine.
I'm not sure how I feel about this, because a single program doesn't own the machine. I don't necessarily want a language to automatically use all the cores any more than I want the language to automatically use all my memory or bandwidth.
I think the GOMAXPROCS approach kind of makes sense. You can spin up as many serial independent tasks as you want, and go will use up to GOMAXPROCS threads.
Re: Why I’m Learning Perl 6
#268Earlier quoted context omitted.
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
aio - POSIX asynchronous I/O overview http://man7.org/linux/man-pages/man7/aio.7.html
In my limited knowledge the only app I've seen use aio is oracle database.
If it works in the sense that the kernel supports the API and implements aoi internally using async mechanisms, then that would be awesome. Is that the case?
Re: Why I’m Learning Perl 6
#269I'll stick with Tcl if I'm going to use a glue language that has green thread like functionality and an event loop. early choices were tcl or perl: went Tcl and never looked back. As far as web development in perl..well have fun convincing everyone on the node.js and python bandwagons to move 'back' to perl. Glad it works for you.
TCL is a fun language, I got my start in web development using OpenACS on aolserver with embedded TCL.
I don't want to go back.
Re: Why I’m Learning Perl 6
#270It's pretty cool to see Perl adding this feature. My rubric for the three big scripting languages (once upon a time?) was: Perl: Good at regular expressions, and proper per-processor core threading, Bad because what you wrote will be indecipherable to future you Python: Very expressive (without being too much), lots of library support, good drop-to-c/do-stuff-fast support, sensible support for object and functional p…
Perl 5's base object system was based on Python's
Ruby has been referred to as Perl 5 with a better object system.
Perl 5 also has Moose an object system based on Perl 6's which has been ported to Python and to Ruby twice.
The way to allow calling into C with NativeCall is almost seamless most of the time. It has also been used to make using modules/libraries from other languages even more seamless. (usually the only way you know the module is from a different language is the :from in the use directive.)