Learning Perl6. It will be the continuation of Learning Perl, but for Perl6 instead of Perl5 I think. My bet is they'll (last edition had 3 authors)continue to publish both as both languages will survive for a long time until Perl6 wins out. There's also the possibility Perl6 just never really takes off, but I hope not.
Brian D. Foy has a WordPress site up for it.
There is a perl6 intro website as well that is awesome.
Brian D Foy has a WordPress site up for Learning Perl6 with some pretty random blog articles. I'd say he's 1-2 years from publishing which is both frustrating and good. The language should be solid by then.
I will say that I started using Perl5 recently (big python fan). I expected everything to be crusty and bad. CPAN worked great, and the doc...my GOSH the doc is sooo good. It is everywhere. In my command-line, gazzillions of websites. I forgot what it was like to not be dependent on StackOverflow.
Perl Monks is far better than Stack Overflow for Perl questions, as they actively encourage the discussion that Stack Overflow avoids, leading to a greater understanding afterwards as opposed to just something that works.
I can't count the # of times a super helpful question was closed on StackOverflow for being "off topic" or being likely to cause a flame war. I do like Perl Monks, but wish the format was a little different UI wise. Def still usable though.
Haskell had a big influence on Perl6. Lazy evaluation is built in to the language just like Haskell. If you look at the bottom of the Perl6 website you'll see the Fibonacci sequence using a lazy infinite list.
Fun fact, one of the original Perl6 implementations was done in Haskell (the parrot VM I think).
Parrot VM is a separate project from Perl 6. It originally started as a VM that could handle Perl 6, but then decided it wanted to focus on being a general VM for dynamic languages. This led to a rift between the two communities.
Before all that happened, though, there was Pugs, which is the Perl-6-on-Haskell thingy that you are thinking of. A fair portion of the current Perl 6 test suite comes from the Pugs project, at least originally. And, IIUC, it was the success of Pugs that revived the Perl 6 efforts and led to the Rakudo project (Perl 6 implemented in Perl 6) which is what we still use today.
So yeah, it is definitely the case that Haskell had a big influence on Perl 6 both from a language design and a more raw "inspiration" in the sense that it literally might not have happened without it -- the original wave of Perl 6 development had largely failed and there was some serious burnout happening. Pugs, Haskell, and Audrey Tang managed to put the ship back on course.
A lot of history happens in 16 years, and I make no claim to know the truth of any of it. There are more than a few rants floating around out there that will give you a picture of what happened when, albeit from a ranty perspective. Hopefully one day it will all be collected in a more comprehensive historical document.
> it was the success of Pugs that revived the Perl 6 efforts and led to the Rakudo project
Note that depending on your point of view, Rakudo actually predates Pugs: It's just that Parrot and Perl6-on-Parrot used to be developed in a single repository, and it wasn't yet called 'Rakudo'.
edit: However, NQP (the basis for the current Rakudo architecture) does indeed postdate Pugs (according to the ChangeLog, it first appeared in Parrot release 0.4.15 in 2007).
Ah, yes you are correct. Thanks for pointing out some of the finer historical notes! I bet there are plenty of people here that would be impressed to know how much P6 has to do with Haskell. I think the general impression isn't one of lots of advanced ideas but Hey Perl finally got a decent object system which is kinda sad lol.
Fair critique. I meant that in the sense that the original vision of Parrot was quite closely tied to delivering a VM which could handle P6. By logical extension, this would mean it could handle any given dynamic language.
However, I am talking about the focus shift that made Perl 6 just one among many of "client languages" (for lack of a better word). This was a distinct moment, at least as far as I remember it.
By logical extension, this would mean it could handle any given dynamic language.
Not only by logical extension! One of Larry's primary goals was to "let any language use the CPAN", through Parrot. Running Perl and P6 on the same VM, in process, without embedding libperl.so was the plan as far back as I can remember.
I am talking about the focus shift that made Perl 6 just one among many of "client languages"
That's been a common, though unrealistic, criticism of Parrot for the past several years. Various contributors never had (or lost) interest in P6 but wanted to work on an multi-language VM. Expecting that all volunteers to a project have the same primary goal in mind is ridiculous and ignores decades of F/OSS contributions; it's easy to look at the Linux kernel and recognize that multiple competing business and personal interests can be shepherded into a technically useful result that meets a lot of those needs despite their competing interests.
People implementing `invokedynamic` didn't somehow make Java a second-class citizen on the JVM, for example.
You can certainly argue that we handled some of those competing interests poorly (I've argued this), but the "focus shift" argument rests on some questionable assumptions and ignores other, more important, concerns.
Hey chromatic, maybe you missed the parts where I explicitly said that my historical knowledge is only as good as the sources I have read (+/- my sideline experience)? Please stop framing my clarifications as intentionally disingenuous. If you have additional historical perspectives to share, then by all means. I even explicitly asked for that in my original response.
Now, I think you are also being a bit disingenuous. The Parrot team shifted focus. You can say all you want that the original vision was always all dynamic languages (which I already said, by the way). But to frame the original Parrot efforts as anything less than building a foundation for Perl 6 clashes with my own memory of the timeline.
If the JVM and the Java teams essentially stopped talking to each other, I would definitely consider that to be some form of collective decision making representing an overall shift in focus for the projects. That's more akin to what I remember of the Parrot/P6 split. Even your post hints at it when you say "Various contributors never had (or lost) interest in P6". But again, I was only "involved" from the sidelines and am limited to the available materials, including yours, and synthesizing them from individual rants into some semblance of a balanced picture.
If the JVM and the Java teams essentially stopped talking to each other, I would definitely consider that to be some form of collective decision making representing an overall shift in focus for the projects. That's more akin to what I remember of the Parrot/P6 split.
That's the story certain people have been telling for quite a while, but it never happened while I was involved in either project. If you look at the use.perl.org archives, you can see that both Allison and I (as the architect of Parrot and a lead developer, respectively) were collaborating closely with Rakudo developers on the weekly P6 design calls.
I understand that, from the outside, there's a natural tendency to take all of the perspectives and comments and assume that the truth lies somewhere in the middle, but the historical record is out there and available. I've certainly referred to it directly when posting my opinions about what happened and when.
I haven't heard of anything in PROD yet (there is a QUORA question on this), but I know there are several Perl shops that would jump on this when it's fully ready. You can use it today for most things (assuming hard performance isn't needed). When the optimizations and JIT are complete, you'll have a very fast OO language with optional types. My intended use cases are for pretty much anything that doesn't need a GUI like a .NET desktop app. I have a LOT of data at work and look forward to using the Grammar functionality to build useful and beautiful parsing code.
I believe Perl6 is bootstrapped by a subsection of Perl6 called NQP (not quite perl)which is written in C.
NQP is actually bootstrapped, so it's written in NQP. NQP in turn has different backends targetting different virtual machines. The backend used by almost everyone is the MoarVM backend (a VM made specifically for the Perl 6 object model, which is written in C), and there's also a JVM backend. The Parrot backend is pretty much legacy at this point, and there's an experimental JavaScript backend.
I remember an earlier Perl6/Rakudo post here (I think), where chromatic showed up and mentioned a few things that had been running reliably for a couple years in his stack. That it was at least "good enough" for his purposes.
Chromatic used to be a proponent of Perl6, defending it against criticism and claims of being vaporware. I don't quite remember when he became a critic, 2010-ish or so.
Around the time when Rakudo further detached itself from Parrot, and declared an effort to support alternative VMs (eventually writing one of its own).
No, I think it was well before that, and he was just more vocal at that point. IIRC became rather disillusioned with the project quite a while back, and he wasn't even involved with it (maybe nominally) at that point.
He put lots of hard work into the project, he wouldn't have done that if he had nothing positive to say. (But sure, lots of stuff have been backported to Perl 5, so the step up to Perl 6 is smaller today.)
He seemed a bit unhappy with some of the internal mess of the development, but that is not exactly uncommon for big projects.
...the primary deliverable ... is the language specification, known as “roast” (Repository Of All Spec Tests) ...
In other words it's roast, the digital acceptance test for any candidate Perl 6 compiler, that is arguably the only thing that was officially declared, and hence the only thing that could be construed to have been officially declared any particular thing such as "stable".
Continuing:
... This Rakudo release targets those tests (over 120 thousand of them), and passes them all on at least some architectures when the moon is in the right phase.
Rakudo is a Perl 6 compiler (so that one can try out the announced language).
Note the moon phase comment. While obviously not literal and arguably misleading it is a brilliantly concise and precise explanation of the degree to which Rakudo, the leading Perl 6 compiler, should or could be characterized as officially "stable".
Damian Conway (Perl5 frequent contributor) is a professor who knows and has taught Lisp classes. He made a good point that although Lisp is powerful in it's own way, you don't get a lot of information by simply glancing at some code. With sigils and other known operators, Perl gives the reader a lot of information as long as it isn't abused.
This is a great point that often get's ignored or glossed over. Perl code is information dense which makes it look messy to someone who doesn't know what each of the sigils and syntax elements mean. What this means is that perl has a longer learning curve but once you get over the hump you know a lot more about what the code is doing in a glance than you do for other languages. So it's not more readable to the new guy but it can be more readably to the ones who put in the effort to get up to speed.
Yea I think the JVM backend was broken recently by a patch (if I remember correctly), but should be fixed soon if not already. I'm surprised it actually works so well when MoarVM isn't 100% done.
I assume the JVM would allow you to use Java libraries as well?
> I think the JVM backend was broken recently by a patch
That's a wrong way to describe it.
There were some important performance related changes to the spec prior to the Christmas release. The focus was on keeping MoarVM backend up-to-date, that's my understanding.
Just use a Rakudo Star release on MoarVM and it will be stable. Since Christmas it will be stable and conform to the official 'Perl 6.C' language specification. A lot of people in Perl6 land keep up with HEAD development building the Rakudo compiler from source daily/weekly with a tool called rakudobrew. HEAD by definition can sometimes be funky, a lot of the reports floating around are use cases against development builds and not official releases. Rakudo improves daily the development is that rapid. With the spec frozen the improvements are mostly performance, relatively obscure bugs and nice things like a better REPL.
I for one am extremely excited for Perl6's ecosystem to grow, documentation to increase, and for the performance optimizations to reach maturity.
Perl5 has raw text processing power, but Perl6 kicks that into overdrive with a much cleaner language (clean and powerful OO with a MOP), with cool goodies from a dozen other languages. I think this may be the first decent contender for the 100 year language if it becomes production worthy.
God I sure hope not. (Only if it's a lot easier to maintain than Perl 5 maybe...)
I have bad feelings about Perl after having to parse and cleanup a bunch of abominably written multi-thousand line pages full of regular expressions and all manner of cleverness. I mean, I actually hated Perl so badly I believed it was the worst invention ever. Then I saw a well written project and was easily able to understand and felt slightly less negative. So it's not entirely the language, but to this day seeing 'Perl' brings negative emotions to the surface. Something like PTSD I guess. It will probably take 100 years for that to go away and me to willingly look at anything called 'Perl'.
Believe me, I've seen bad Perl[1]. Luckily I was already very familiar with Perl, so I was able to discern that the developer was just batty.
1: Global variables everywhere. Every function call did not pass arguments, but instead they assigned data to global variables in the immediately preceding lines, called the function, and then used those global variables. Copious use of SQL where every query was saved in a variable called $stmtA, $stmtB or $stmtC, depending on how many levels of sub-querying needed to be done in a loop. Obscure variable names in general. Zero comments. No use of modules, everything in one flat text file (for 5-10 or more flat text files), no code reuse. PHP used in the same project, to the same standard (one large sprawling multi-thousand line PHP file). This was an open source project, and to this day I wonder if possibly it was all a purposeful design decision, so they could charge for development requests.
Personally, I think a lot of the bad Perl code people have had to deal with relate back to three things.
a) Many of people writing the code were sysadmins that just needed to get a job done, and didn't have much real development experience.
b) Perl was also easy to get access to in cheap shared hosting environments, so it attracted other people without some development discipline.
c) Perl4 did not have objects, and scoping was limited to local(). Thus, lots of spaghetti code and global vars.
However, none of that would have gotten exposed to developers if their teams had decent interviewing techniques, or code review, etc.
All that to say that Perl 6 shouldn't have the same propensity for bad code to end up in a real project. Any more than any other language that is. I can certainly misuse regexps, lambas and other features and write some hard to maintain Python.
100 year language might be meant seriously by some people, but I meant it as something that has enough powerful concepts to stay relevant for a long time.
It harks back to Paul Graham's essay where he started off on Arclisp as a 100 year language and better designed lisp. Other priorities came up and it didn't really go anywhere besides maybe being used for this website. Hopefully Perl6 doesn't suffer a similar fate.
Perl gets proper OOP, as now that OOP seems to be out of fashion!
(I wish the fashion part of our industry would disappear and people would use the correct tools appropriately. OOP still has plenty of valid cases in my opinion).
OOP isn't out of fashion, per se, I don't think. Inheritance is what really went out of fashion. Part of the problem, I think, is that people use OOP and Inheritance interchangeably too much.
objects are just syntax sugar for a closure or a set of curried functions. As such they are useful. It's inheritance that gave OOP a bad name.
I still recall reading ECOOP papers in the 80s that made it very clear that composition is a much better approach for most things than inheritance (and that a single inheritance mechanism is generally much simpler than a multiple inheritance one).
But, while Larry Wall agreed in the sense he put emphasis on features such as roles (cf Haskell type classes) he has also said that there are some important scenarios in which inheritance (and very occasionally multiple inheritance) make coding a solution to a problem more straightforward where use of composition makes it less so, so standard Perl 6 supports both composition (eg roles) and (multiple) inheritance and the compiler (which is written in Perl 6) uses one or the other based on whichever is deemed to work best.
Curious what about Perl 5 OOP makes it not proper. Is is just the required constructor boilerplate, like bless()? Or is it the lack of enforced private methods?
Neither seems like a showstopper to me...honestly curious.
Perls OOP was an afterthought and it does feel a bit of an add on rather than a core part of the language.
Having said that I got my first job using Perl after learning Java at university. It actually helped me understand OOP and inheritance a lot better because it was so transparent compared to Java's OOP which seemed more of a black box - it worked but I never really knew how.
Brian D. Foy has a WordPress site up for it.
There is a perl6 intro website as well that is awesome.