chromatic writes about Perl, and hosts the free online Modern Perl book along with posts on the language and its community.
Commenters call the Modern Perl book great and brilliant for explaining readable Perl 5 to modern readers, and recommend reading it free or buying it.
I get that this is an issue that bothers PG. I also get that this particular comment you're singling out might be an example of it, but I'm not sure. However, I'm not convinced that every instance that looks like the alleged problem is really a problem in itself and, perhaps I am in a minority, do not believe this sort of thing is the downfall of HN.
For me, I think the issues that make discussions go "downhill" are less to do with criticism and much more to do with prevalence of group-think. I don't think the prevailing wisdom that pointing out fundamental errors of facts of faulty arguments is a bad thing, even if they are not the main point of the article. I think there is edifying value in such criticism. Now, it is true that an article may have value beyond it's minor or major inherent fallacies and errors. Criticism is not censorship and it does not prevent others from reading and discussing other parts of an article if they are interesting and fodder for good conversation. Nevertheless, I don't think being overly generous or charitable necessarily the best method or should be enforced via an algorithm or community brow beating. No one wants inane Reddit conversations but I don't think most want sterile group-think or hug sessions either.
HN has all kinds of users with different backgrounds and some users are very knowledgeable and critical and we can learn a lot of have great discussion regarding the criticism as the more traditionally positive style conversations.…
I want to write something concise and coherent, but it's not happening today :) Instead, assuming you've read the teasers in the Moose manual [1] I'd recommend this [2] interesting comparison of how horizontal code re-use can be achieved in Java, Ruby, PHP and Perl+Moose. There's more philosophical/winding essays on Moose from Chromatic, for example at [3].
Roles/traits/method modifiers/MOP/composability etc. are all great things for getting more reusability... however (and this might sound stupid) the thing that saddens me most when writing Python code is when I find myself adding a bunch of asserts or adding program logic "manually" in situations where I'd normally specify that sort of thing declaratively in a Moose class definition or by referring to a centrally managed Type or delegate stuff through attribute features.
On the other hand, I'm barely into year 2 of full-time Python dev, so perhaps I've yet to find the idiomatic way of doing Python things I used to take for granted in Moose.
Regarding Perl 6, I don't know much about it, except that the original authors of Moose had some inspiration from it.
Is picking up Perl+Moose mind-expanding? It was for me, but I feel that what Moose gave me in Perl was a bit of a band-aid over the fact that it's such a malleable open-ended dynamic language. So as a C++/Java programmer this aspect might not be so enlightening to you, except to see how Moose achieves it in a pretty painless way that I think is very nice and…
Basically, I guess, I would like something like the Camel book for Perl 6.
There was one published by O'Reilly about ten years ago, but of course back then you could not say "apt-get install perl6" or something equivalent. Also, the language definition was far from finished, back then, so that book is probably totally outdated by now.
The Perl community, as far as I can tell, has no lack of talented writers, so I am optimistic something will be written before too long.
Another reference you might want to look at is "Modern Perl" (http://modernperlbooks.com/).
And really, I would like something I can read offline, preferably as a PDF. I know we live an always-online age, but really, I want something I can read on the train where I have no Internet access, and I want to be able to search the documentation without having to send a request to a web server.
I am aware there are of http://www.perl6.org/documentation/, but the docs there seem to be ... not organized in the way my brain is used to.
Another reference that just comes to my mind is the Python documentation, which IMHO is superb. It's well organized, concise and to the point, without being spartan.
Just to be clear, I do not expect you to do all that work, but if you want starting points what I would like Perl 6 documentation to look like, now you know. ;-)
Old debate, it's a core philosophy or the language. It's a bit like complaining that there are a 100 ways to cook chicken.
Personally, I like the freedom that Perl offers. Perl 5.x is still widely used in some industries, finance and banking for instance, and it's still the glue that holds 'nix systems together (have a look at the scripts in the bin folders of any distro).
Following Modern Perl[1] best practices, you can write powerful, meaningful and expressive Perl 5 without shooting yourself in the foot.
Perl 6 is another beast, it removes many of the ambiguities present in Perl 5 and introduces more functional paradigms.
At its core, Perl remains a multipurpose tool. The fact that there are multiple ways to do a thing is not bad, whether it suits you or not is a matter of personal preference really.
So, if someone is curious about Perl, they should be encouraged to try it and find out for themselves if they like it or not.
[1] http://modernperlbooks.com/books/modern_perl/
Perl5 has linters (Perl::Critic, Perl::Lint). And warnings to keep you from using ugly features (if you assert compatibility with the 2010 release 5.12, strict mode is automatically turned on).
JavaScript actually copied its `‘use strict’` syntax from Perl's `use strict;` which in Perl is using a pragma, not a magical string literal that reconfigures the compiler.
You want types? Several systems exist, but the leading implementation is Type::Tiny.
A big part of Perl culture in the late 2000s and early 2010s was focused around rooting out horrible old practices and tutorials, defining good practices, and getting tooling to help. Perl Best Practices came out of in 2005. Some effort to describe these tools and techniques as “modern Perl” followed—check out the inaugural entry of the Modern Perl Books blog from 2009. http://www.modernperlbooks.com/mt/2009/01/
Since Perl5 did what you’re asking for, maybe you should check it out and see what Perl 5 looks like in 2019.
If you haven't played with Perl lately, it's worth looking into Moose, an object system for Perl. It not only offers a much nicer syntax for making objects, but provides features like read-only accessors, roles, introspection, and even types! http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod
I work with Perl professionally now after having spent most of my self-taught programming education using Python, and I've been pleasantly surprised with the language. I'm both coding new projects and working with a more than decade old code base, and I've found that Perl code is as good as the programmer.
Yes, like any decades old language it has its warts, but Perl 5 itself is still being developed and improved upon. For those who know another scripting language, the free book Modern Perl is a great place to start learning: http://modernperlbooks.com/books/modern_perl_2014/