I learned more about you than about Dominus with that comment.
Here is a link to his well received book, by the way: http://hop.perl.plover.com/book/
(But the book you should probably look at to understand the world better, is "Perl best practices".)
Edit: fuzzix -- you are certainly right about most useful modern books, I was making a point to what I comment on. The idi.. cough.. Which insinuated that readable code is an unknown concept to typical Perl programmers.
If you're going to argue that Perl is readable code then I'm going to have to disagree with you extremely after having been in a position to maintain some Perl code before.
>>after having been in a position to maintain some Perl code before.
Sigh... You "supported some code" and know how modern Perl looks like?! :-)
Could you carefully explain e.g. the problems with Moose and the latest [syntax] extensions you find on CPAN?
To start with.
Making wild claims like that without support makes you seem like a language war troll or a complete asshat. To be taken seriously, show that you know what you make such big claims about.
Edit: And since you have nothing to say about the subject matter -- what is it in the Python culture that brews such fanatic language war trolls? (I assume you're a Python guy?)
No, I am questioning your specific claims about things you obviously have no clue about.
That was a pathetic attempt to change the subject. I stop waiting for a serious answer from you now. Bye.
Edit: And if you're a high schooler, sorry if I'm brusque. There is too much of this language war garbage on HN, I want to keep the quality up.
Your opinion is a complete generalisation and makes you sound profoundly ignorant. Language choice != coding ability.
It is true that one way to do something is foreign to Perl culture. It is also true that the best Perl code is pretty unreadable if you expect to read it as a C/C++/Java programmer. Perl is a very different language, and good Perl code reads very differently.
I am not going to get in a language war of Perl vs Java. Both languages have their places. I prefer Perl on the server. I prefer Java on clients I have no control over because at least I can hope it has a working JVM.
Readable Perl code is just different from Java. Let's take an example:
package Foo;
use Moose;
use PGObject::Util::DBMethod;
with 'PGObject::Simple::Role', 'Baz';
has id => (is => 'ro', isa => 'Int');
has name => (is => 'ro', isa => 'Str');
has description => (is => 'ro', isa => 'Str');
dbmethod int => (funcname => 'foo_to_int');
dbmethod get => (funcname => 'get_foo');
dbmethod save => (funcname => 'save_foo');
There is nothing unreadable about that. It provides a package with declarative specifications for properties and accessors (all of which are read only) and methods which delegate to PostgreSQL stored procedures (more information of which is probably further clarified in the Baz interface.There is nothing inherently unreadable about Perl.
[1]http://ledgersmbdev.blogspot.com/2014/02/in-praise-of-perl-5...
The perl code I've seen in the wild generally doesn't look like that though. Is that more an issue of the age of most Perl code? Or are some people still writing 'old fashioned perl' even if it isn't the recommended way anymore?
See e.g.
http://search.cpan.org/~mauke/Keyword-Simple-0.02/lib/Keywor...
http://search.cpan.org/~mauke/Function-Parameters-1.0401/lib...
What seems to happen the coming years in Perl 5 (unless the Python language trolls manages to discredit it enough to kill it :-) ) is probably gelling around language [syntax] extensions and Moose going to the Perl core.
But it will still keep backwards compatibility.
(And I write horrible Perl code most days myself, as one line liners. :-) Best damn shell functionality on this planet imho, along with Emacs command line editing.)
So it's complicated.
Also keep in mind that a lot of CPAN modules out there began back in the 1990's and are still being developed today. I know. I am now a maintainer of several, and the code isn't often that pretty.
But this is the benefit of being encouraged to think about elegance of code: one improves.
But one can write amazingly beautiful, clear, and elegant Perl or one can write rubbish (after all good Perl doesn't take much work to maintain). Most of my work is either maintaining rubbish or (I hope) writing nice, maintainable code.
Some of the non-CPAN code I have (the rubbish) is sufficiently unmaintainable that the only way of dealing with it is to refactor with a chain saw and avoid touching it otherwise.
1. I like Perl.
2. Imo, if someone doesn't see advantages to TSBOAPOOOWTDI then they don't understand it -- and the same is true of TIMTOWTDI, TIMTOWTDIBSCINABTE, and many other useful generalizations.
3. I love readable code.
I think the above three statements also apply to Larry Wall (the creator of Perl) and many others in the Perl community.
Imo "Someone who likes Perl is not going to be appreciative of 'one way to do something' and 'readable code'." is not a useful generalization.
If the universe applied different rules to me than everyone else I might advise folk to take any opinion from someone who generalizes without sufficient respect for the dangers of generalization as coming from someone who generalizes without sufficient respect for the dangers of generalization. But it doesn't, so I won't. :)