Python is a beautiful language too! Perl has its own strengths. In order to win as scripting language on the UNIX environment a language will have to get some things right very well. Two of them namely 'Processes' and 'Files(text)'. UNIX is really about these two things heavily. That is why you will see UNIX by a vanilla installation has shipped with tools like sed, grep, awk, cut, tr, cat and other text processing tools for decades. Because a file can act as a pretty good representation for data, storage and problem representation use cases. Another area that the language will have to get…
I'd really like to follow up on this recommendation: I used Perl first as a kind of sed and awk on steroids in the dark days on a VAX running BSD 4.3, wrote simple CGI in it in the early 90's then later recoded a fax gateway in Perl 4 on Solaris 2.4. Like many people, Perl for me was a useful tool, but regularly unreadable, and admitting of very few good practices. In the end, I moved across to other domain-specific languages and only dived into Perl infrequently for data analysis tasks during the last 10-15 years. Writing the same old unmaintainable, unreusable, script-like code, and hating…
One can build anything in any language(considering the mathematical possibility). So by this definition we can all go back to building in Nand gates. But that is not what its all about. Languages get used because they do a certain job well. Perl does, what it was designed to do very well. That is precisely what Larry wall's water bed theory of complexity is about(http://en.wikipedia.org/wiki/Waterbed_theory). You have a problem with CPAN? With CPAN, really? A ecosystem that is considered as a killer feature which no other language has managed to emulate so far? And Perl is monolithic????…
The idea that there is some under-appreciated, reliable technology that's already solved a lot of problems people are trying to address today is compelling to me. In fact, I've learned that I almost need to actively ignore short pieces of advocacy in order to keep them in perspective. "Modern Perl" is an improvement on the coding styles that earned statements like "write once, read never". However, I think it is relevant to read "The Mid-Career of the Perl Programmer"[1] written by chromatic, who wrote the book on Modern Perl. Realistically, the audience for this article will probably be…
Trying to do OO stuff without the mighty MOOSE? Whoa, retro, man. MOOSE came out about a decade ago. Awesome OO implementation, no point using any other technique. He's calling "open" in a way thats been a no-no since like Clinton was prez, or at least a long time ago. You can debate making filehandles plain ole variables or not. The cool kids do it a different way than he does, which is not necessarily wrong. Backticks are looked at about the same way... so how exactly do you handle stdout/stderr separately with backticks, oh you don't, um... There's another, better way to safely…
Full disclosure: I'm the guy who made http://perl-tutorial.org a few years ago because the top google result for "perl tutorial" was a perl 4 tutorial. I have looked at many tutorials and have a vested interest in getting quality tutorials in people's hands to avoid them writing shitty perl. That said, this tutorial is terrible on a number of points, since it teaches outdated things that have long been known to be dangerous and are only kept around for the sake of backwards compatibility. Reading it is wholly a waste of your time, unless you already know perl like the back of your hand and…
(Second try at this) First, anyone who says that Python or Ruby is not even comparable to Perl is full of it or very mistaken. They are close enough that we quickly run into the narcissism of small differences [1]. Second, in my experience HN ranges from uninterested to hostile when it comes to Perl. I read lots about Perl, but many of the blogs or forums I frequent are Perl-centric. My point is simply that you shouldn't judge by "what you read" if what you read is a function of what you choose or who you follow. Third, and most importantly, the Perl5 community doesn't seem anywhere near…
This doesn't make much sense. If anything, I'd argue that the Perl community is taking a page out of Python's book with their recent emphasis on readable code, best practices and things like "use strict" over the freewheeling hackery that formed Perl's reputation. I'm not sure what I'd recommend to the author if they prefer a less prescriptive community, but it certainly wouldn't be either Python or Ruby. Maybe something from the Lisp family, like Racket? On a side note, the very things that the author complains about are the same things that have been motivating me to learn Perl…
There are two issues in this thread. First, a confusion: this book has nothing to do with Zed Shaw's Learn X the Hard Way series. (I have no idea if Zed ever heard the title even. He may have come to it - the title - completely independently.) This book predates Zed's series, and has a very different goal. Zed's book, as I understand it, targets novices. The difficulty in the title is that you must do all the exercises and learn from a lot of repetition and trying things on your own (as well as looking up docs, further examples, etc. online). The Downey book, on the other hand, is aimed at…
If reading regexes you wrote is a pain point for you, then you're not making as much use of the readability tools Perl provides as you could, i.e. the /x modifier to make unescaped whitespace insignificant, and in-regex comments. ( http://www.perl.com/pub/2004/01/16/regexps.html ) And well, honestly, more often than not i found that "hard to read" perl code would be just as hard to read if it was written in lisp, python, c, or any other language you care to name; since more often than not that code is hard to read due to variables and functions having names that don't help the reader…