41–46 of 46 posts
Obviously you should never use any of these in a production code base. Perl lets you write very bad, anti-team unreadable code in countless ways. You have to actively avoid these traps designed as neat toys.
I have been using Perl since 1996, but I only use a handful of the secret operators. For me, the power with Perl is CPAN and the stability of Perl 5.
If you are working on a code base with others, it would be cruel to use some of these. However there are operators that could be beneficial to the advanced Perl users.
Earlier quoted context omitted.
I think there's a difference between "baby talk" and using Perl as Perl. You can write Perl that looks like Python, or C, or whatever, but you're missing out on what makes Perl, Perl. "baby talk" Perl is another name for being able to much with Perl, knowing very little of it. Also known as, "Getting your job done". It's up to the individual to learn more about the language, which can be done gradually, much like a n…
you're wrong though: it's not just up to the individual to learn more about the language, it's also up to to every single person who maintains that code afterward! If you learn something, you force your maintainer to learn it. This is particularly true because many syntax elements are literally impossible to Google. If you didn't happen to learn some idiom (syntax), you just can't deduce or discover what it does, unl…
I would encourage you to check out some of the more recent tools and books on Perl that help greatly in making code readable and maintainable, like the Modern Perl book, the Perl Best Practices book or things like Moose - or even if I dare say, Perl 6.
The Perl Community has come a long way since when I started in 1999, that's for sure. So has the entire Industry, to be quite honest.
Earlier quoted context omitted.
When I first learnt perl, twenty years ago, I loved it because it was full of clever devices and syntactic virtuosism. Now, I don't like it anymore exactly for the same reason. It's cool, but the wrong kind of cool.
That's exactly the problem with Perl: cleverness -- especially other people's "cleverness" -- gets to be tedious, if not an outright pain to put up with and maintain, after a while.
Earlier quoted context omitted.
Mostly it was all the terrible code that got written in Perl by the first wave of non-programmers to start building web apps.
So, same fate as PHP?
Perl, as confusing as it can seem, has fairly consistent rules that it follows. Learning those and keeping them in mind will generally let you intuit how something is expected to work.
Earlier quoted context omitted.
I think there's a difference between "baby talk" and using Perl as Perl. You can write Perl that looks like Python, or C, or whatever, but you're missing out on what makes Perl, Perl. "baby talk" Perl is another name for being able to much with Perl, knowing very little of it. Also known as, "Getting your job done". It's up to the individual to learn more about the language, which can be done gradually, much like a n…
you're wrong though: it's not just up to the individual to learn more about the language, it's also up to to every single person who maintains that code afterward! If you learn something, you force your maintainer to learn it. This is particularly true because many syntax elements are literally impossible to Google. If you didn't happen to learn some idiom (syntax), you just can't deduce or discover what it does, unl…
Learn the language you are writing code in, and use idiomatic code for that language.