$^P |= 0x10 ... debugging support,
keeps info about source
lines on which a subroutine is defined
The third line of code is a workaround for a bug, documented in the comment above it.
If you were Chinese, would you complain that English words have no meaning to you?
The 'look at the xyz CPAN modules!' argument
doesn't really cut it for me.
The libraries available are the most important asset of a language, more important than the language itself.
Example: I just chose Ruby instead of Python for a project and I just discovered that there's nothing like PIL for doing image processing in Ruby. The alternatives are so bad that I'm thinking about rewriting the whole thing in Python.
As far as CPAN is concerned, it's a really big (maybe the biggest), really comprehensive, centralized repository of libraries.
CPAN also has something that RubyGems / the Python Index or the Maven repositories do not ... http://cpantesters.org/
I think you are missing the point here. I'm not saying Perl is hard or impossible to program, or that it is 'bad' or anything, just that Perl code very often comes out obfuscated and hard to interpret, even for someone who knows many other programming languages.
Example: instead of '$^P |= 0x10', something along the lines of 'sys.debug = True' is a lot easier to read, right? Perl code is full of such examples, I could make up at least 20 examples from the module linked to before in this thread, all using alternatives resembling different other languages, and all much easier to interpret.
The problem with Perl (as far as I can judge) is that it tries to cram too many different things into operators and magic variables, and that it allows too much wonky stuff that might come in handy to shave off a few characters if you are a guru, but could just as well have been left out, sacrificing compactness for readability. Another thing that Perl seems to lack is orthogonality, I always get the impression that the language allows you to solve the same problem in 10 different ways.
Just to give a counter-example, take a look at Objective-C code, which is almost the antithesis of Perl. It's almost self-documenting because of the naming conventions, named parameters, the way the frameworks are designed, etc. Sure, it's about 10 times more verbose than Perl, and the core language probably has 10 times less features, but if you have a good editor and don't try to obsessively do things 'your way' instead of 'the Objective-C way', it's a joy to work with.
If you spend enough time in the Perl world, of course you'll get used to the language features and syntax of the language, and forget about how long it took to get to that point. At that point it's probably a perfectly fine and powerful language that allows very fast development.
> The libraries available are the most important asset of a language, more important than the language itself
100% agreed, but most other popular languages also have huge libraries (core SDK libraries or third-party). At some point you reach some kind of critical mass where you can solve 99% of the problems using native libraries, leaving only 1% that requires bindings to e.g. C/C++, shell exec, RPC, etc. Most other languages already reached that point or make it easy enough to interface with other languages that have more libraries, to the extent lack of libraries is not an issue anymore (such as Objective-C, for example).
> Another thing that Perl seems to lack is orthogonality, I always get the impression that the language allows you to solve the same problem in 10 different ways.
This is a deliberate feature of Perl, whose motto is "There's More Than One Way To Do It".
Not to defend the practice, since the fact that there are 10 ways to do something means that (1) there's a 90% chance that when you look at somebody else's code you can't understand it, unless you learned all 10 ways and (2) at least 50% of those ways are objectively worse than the alternatives, but people will still use them because Perl programmers are encouraged to solve problems in whatever way they can.
Contrast with Python, where "There should be one - and preferably only one - obvious way to do it".
For the rationale behind it, read this article by Larry Wall ... http://www.wall.org/~larry/pm.html (really, it's one of the best language-related essays around).
Contrast with Python, where "There should be
one - and preferably only one - obvious way to
do it".
As a Python developer myself, I call that bullshit ... how about 2 urllibs in the standard library, both broken and a dozen or so XML parsers and I still have to install PyQuery to remain sane.
Also, its one obvious way to do it also breaks down in the language itself, like there's still a difference between old-style and new-style classes. And because the language does not have anonymous code-blocks (something which Perl has), the language designers added a bunch of features to take care of certain use-cases, features which are not orthogonal, like lambda expressions, foreach blocks, with blocks, iterators AND decorators, all of which could have been avoided by adding just a simple feature.
If you ever try building a simple DSL, something that modifies a class at runtime, you'll have about a dozen or so techniques to use, but none of them as beautiful as ActiveRecord ... which relies on the fact that a class block in ruby is just syntactic sugar for opening a class context with define_class and passing it a code block.
I know more about Perl than I do about Python so I can't comment on Python's execution of its chosen philosophy, but I certainly prefer it as a philosophy of programming language design.
RMagick is a leaky, slow and unmaintained piece of software. It is also used only for small retouching on images, the primary use-case being to make thumbnails. PIL on the other hand is more reliable and can do things that RMagick does not, like actual drawings or to put it another way, whatever you can do with GDK, you can do with PIL, all in one nice package.
PIL is not perfect either, but there's nothing like it for Ruby.
I can't argue about it not getting much love in the updates department and its instability under many configurations (though sometimes you can get lucky ;-)), but..
and can do things that RMagick does not, like actual drawings
RMagick has a SVG-related drawing system called RVG:
From http://perldoc.perl.org/perlvar.html ...
The third line of code is a workaround for a bug, documented in the comment above it.If you were Chinese, would you complain that English words have no meaning to you?
The libraries available are the most important asset of a language, more important than the language itself.Example: I just chose Ruby instead of Python for a project and I just discovered that there's nothing like PIL for doing image processing in Ruby. The alternatives are so bad that I'm thinking about rewriting the whole thing in Python.
As far as CPAN is concerned, it's a really big (maybe the biggest), really comprehensive, centralized repository of libraries.
CPAN also has something that RubyGems / the Python Index or the Maven repositories do not ... http://cpantesters.org/