That is by far not the norm for code written nowadays by CPAN authors who are aware of advances in the art. Have as an example the code in the very first module featured on frepan.org at the moment: https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/M...
# Turn on the debugger's symbol source tracing
$^P |= 0x10;
# Work around bug in pre-5.8.7 perl where turning on $^P
# causes caller() to be confused about eval {}'s in the stack.
# (See http://rt.perl.org/rt3/Ticket/Display.html?id=35059 for more info.)
eval 'sub DB::sub' if $] < 5.008007;
As someone with a 2-digit number of years of experience in 4 different programming and casual experience with about 4 others, I couldn't for the life of me have figure out what that code does, if some hadn't commented it.
The rest of the code looks a bit like PHP by the way, except uglier (not trying to flame here, just my opinion).
Maybe some day someone will be able to explain why anyone in their right mind would voluntarily choose to program in Perl, if not because of prior experience with the language, or some form of religious beliefs. The 'look at the xyz CPAN modules!' argument doesn't really cut it for me.
$^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:
Literally the only hard part there are the magic variables, which one can look up easily as long as one knows that they're all listed under `perldoc perlvar`. (Though i'd like to mention that he should've used `use English;`.)
Either way, my point still stands. I took an entirely random and fresh piece of code and aside from one tiny well-documented bit, all of it is easily readable and most importantly: Extremely different from the code example used in that study.
The rest of your comment does not merit discussion because you've your prejudices and are content with them.
> Literally the only hard part there are the magic variables [..]
Sure, I'm not even saying that stuff like this makes Perl 'hard', just obscure and in many cases obfuscated. I have no idea whether you could write non-trivial Perl code that doesn't use magic variables or weird operators, but every piece of Perl code I have ever had to read or debug/maintain has suggested it's an integral aspect of the language. Maybe I've just been unlucky so far...
The code you linked to contains lots of other weird and obscure stuff by the way, I just picked the first routine to make my point. To illustrate it in another way: I challenge anyone who doesn't know anything about Perl to explain why there is another block labelled 'BEGIN' at the end of the module, which goes like this, and what it is needed for:
Imagine having to come up with this if you are new to Perl programming :-S
> The rest of your comment does not merit discussion because you've your prejudices and are content with them
That's funny, I hear the exact same thing every time I ask someone about what makes Perl great, and how it stands out from any other language. Somehow I never get a real answer, just accusations of being prejudiced or anti-Perl.
I'm not against any programming language (except maybe VB ;-), I'm just curious why Perl is still relevant for anything except legacy code, now that we have so many nice languages for almost every problem domain.
> I challenge anyone who doesn't know anything about Perl
Now that premise in itself is silly and you know it. (I could get a code sample for any language that would be impossible to understand by someone who doesn't know anything about tha language and it wouldn't even have to be a complicated one.)
> I'm just curious why Perl is still relevant for anything except legacy code
Few languages are as evolvable as Perl. Nowadays Perl has a better object system than Ruby and the only hard part is getting it into the core.
Also, i should probably point out that i got a tad unlucky in that the first example i grabbed was meant to do some fairly language-integral stuff, namely reloading all the libraries already loaded into memory: https://metacpan.org/module/Module::Refresh
>Now that premise in itself is silly and you know it. (I could get a code sample for any language that would be impossible to understand by someone who doesn't know anything about tha language and it wouldn't even have to be a complicated one.)
The difference, and reason his statement is relevant, is that perl is one of the easiest languages to find these kinds of examples for. Where there is smoke, etc.
>Few languages are as evolvable as Perl.
[citation needed] Are you aware of what is being done in other languages. Does perl run on the JVM yet?
>Nowadays Perl has a better object system than Ruby
This is a subjective statement, right? If not, I'm afraid I'm going to have to ask for citations again.
>and the only hard part is getting it into the core
Oh, right. So as a new programmer I'm going to have to dig around to figure out how to pull things in to make the language modern after I've already gone through the trouble of getting it setup? I saw a "modern best practices use recommendation" one time. There were like 25 or so (I'm not even joking) use statements at the top of the file. If you give me 25 lines to pull stuff in I could probably make BF usable.
> The difference, and reason his statement is relevant, is that perl is one of the easiest languages to find these kinds of examples for. Where there is smoke, etc.
Entirely by virtue of there existing a bulk of legacy software. Most other dynamic languages do not even have an appreciable amount of legacy software.
If i were to restrict myself to searching only the past 5 years of produced Perl code on CPAN i would be hard-pressed to find truly terrible samples.
Either way you managed to entirely miss the point that for a person with no knowledge about a language (including no knowledge about sibling languages), any example of source would be nearly impossible to understand at first try.
> [citation needed] Are you aware of what is being done in other languages. Does perl run on the JVM yet?
I said language, not virtual machine.
> I'm afraid I'm going to have to ask for citations again.
When does Ruby plan to have Roles?
> I've already gone through the trouble of getting it setup
Hahahaha. Trouble setting up perl, good one, pal. Also, i know what sample you saw once. That was written as a joke. It is a boilerplate tchrist made to demonstrate what would be necessary to make scripts entirely and absolutely perfect with unicode. (Note: Perl's default state is still better in handling unicode than most other languages.)
> So as a new programmer I'm going to have to dig around
Right now, yes. Which is why i wrote the blog post mentioned above. How kind of you to notice.
>If i were to restrict myself to searching only the past 5 years of produced Perl code on CPAN i would be hard-pressed to find truly terrible samples.
Well, it depends on what you mean by "truly terrible samples". If you mean "things the thread-OP couldn't understand" then I would be surprised if your statement is correct. Was the example he provided from CPAN?
>I said language, not virtual machine.
People are doing "crazy" things in every language. Including porting them to the JVM so they can use the whole body of Java libraries (which is more than what's on CPAN btw).
>When does Ruby plan to have Roles?
I'm not a ruby guy but ruby has mixins which fill the same niche (even if they probably behave a little differently to accomplish it).
>Trouble setting up perl, good one, pal.
It depends. If I'm on a modern Linux, sure, if it's not already there I can apt-get it. That's not always the case though.
>That was written as a joke
I'm pretty sure the one I saw from Chromatic. It had various Moose stuff in it as well. Surely you don't have to pull in the whole OO framework to get unicode to work?
>Right now, yes. Which is why i wrote the blog post mentioned above. How kind of you to notice.
So finally you accept a criticism. But only the one you made yourself already. And they say Rails is a ghetto...
I'm not a ruby guy but ruby has mixins which fill the same niche (even if they probably behave a little differently to accomplish it).
Mixins don't even compare to roles; mixins in Ruby (at least Ruby 1.8 this was true) manipulate inheritance, and so they suffer from ordering problems. The compiler can't warn you about collisions and conflicts.
Of course they do. They may not be as good as perl's Roles but you can't say "Ruby doesn't even have a way to do this" as the GP did (paraphrased). They do, perhaps it's not as nice but it's there.
One of the explicit design goals for roles was to solve the flaws of mixins. We succeeded. While it may be technically correct to object to a hyperliteral interpretation of an English idiom, I stand by the assertion that the presence of roles in Perl 5's Moose and Perl 6's object system makes for a better object system than Ruby with mixins.
Man, please, you could at least read the whole thing. I provided the sample, randomly pulled from CPAN and that dude harped on one small extract.
> mixins
Hm, gonna have to admit i have no clue about those. Will read up at some point.
> It depends. If I'm on a modern Linux, sure, if it's not already there I can apt-get it. That's not always the case though.
Perl is on every linux, no exception. It may not be the newest one, but even then you can use perlbrew to install whatever version you want for your own user account. But seriously, perl is on every linux.
And even on windows it's as stupidly simple as downloading an installer and clicking 5 times.
> moose ... boilerplate
You wouldn't include Moose in a boilerplate thing.
> criticism
I work daily with Perl, i've considered MANY criticisms, i have a whole book of criticisms of my own. The problem you're running into is that i've already spent a hell of a lot more time thinking about those criticisms than you have.
>I provided the sample, randomly pulled from CPAN and that dude harped on one small extract.
I missed that part. But I find it highly amusing that you randomly pulled a sample file from CPAN an already failed your own test.
>Hm, gonna have to admit i have no clue about those. Will read up at some point.
Fair enough, but I feel compelled to point out that you've been harping on me all over this thread for not reading things yet you declare perl's OO (bolted on via a library, no less) superior to ruby's without even knowing how ruby's works.
>Perl is on every linux
Linux yes. Not every Unix, not every Windows.
>You wouldn't include Moose in a boilerplate thing.
It was. It was a boilerplate list of things one should use to make perl a modern language. I think they wanted to make one module that did all these uses for you so you could just use that, but the point remains. It takes a lot of modification to stock perl to bring it up to the level of the competition.
>The problem you're running into is that i've already spent a hell of a lot more time thinking about those criticisms than you have.
I worked daily with perl for half a decade. I can believe that you have spent more time thinking about the criticism because you apparently like perl. I had no emotional attachment to it so when I saw languages that didn't have those problems I left it and never looked back.
Wait, you'll only consider languages that come pre-installed on all Unices and Windows? That's a pretty short list!
Or are you complaining that Perl isn't available for some Unices or some versions of Windows? I'm curious to know what version of Unix or Windows has Python and/or Ruby interpreters available, but doesn't have Perl.
No, you've completely misunderstood my post. I was saying "I have to do all the effort to install perl and then I still have to do more work to actually write a program". We then took a detour where it was claimed there is no effort involved in installing perl. Well, sometimes there is. There is with other languages too, but at least once I have them installed I can just use them without having to go read about about current use statements I should be using.
Most of the ugly code can be avoided nowadays.. but for special cases (as that one) and a few not-so-special cases, the code can get ugly. At least until you get used to it ;)
Also, perl is very flexible which is a good thing. But for better or for worse, perl lets people do crazy things.
Actually, that flexibility is one great things about perl. If you know what you are doing, you can adapt the style for the purpose. For example, hack together something fast, and if it looks like a viable solution, flesh it out into something more maintainable. This is true for other languages as well, but IMHO, even more so for perl.
When ever I hear people sing the praises of perl it just always make me think most haven't really sat down and learn many other languages. It's like hearing an English speaker say something like "man, English is so great because you can... like, express yourself in it! And there are even lots of ways to express yourself in it! And you can express all kinds of stuff!". Great, so it's like all the other languages then?
There's different things being discussed here at this point.
You're saying "CPAN authors don't write crappy code". Fair point, but CPAN authors aren't looking for tutorials, nor are they writing tutorials (otherwise, they'd be tutorial authors, not CPAN authors).
The original point was that googling for tutorials brings up old crappy code. What modern perl experts write has no bearing on this issue.
What's needed is an concerted effort to have those talented CPAN authors focus their efforts on writing modern tutorials, publicizing them, getting linked, and also contacting owners of older tutorials and asking them to link to the modern stuff.
It won't happen overnight, but there's a cyclical downward spiral with perl that needs to be stopped. People looking at old/bad perl tutorials may never get to the point where they even learn about or use CPAN in the first place, and won't get exposed to better techniques. Many tutorials in other languages are bad, of course, but compare a bad PHP tutorial to a bad perl one, and the PHP will still be easier for newbs to grok.
Let me just point out that i wrote the linked blog post. :)
I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies.
>I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies.
Unfortunately, I'm not sure if this is going to help all that much at this point. I think the main group of people that use the current, rather poor tutorials are newbie(or even experienced) developers that have inherited Perl code that uses the language in a way that they have never encountered before. Those devs need a good way to find all the insane single character typing optimizations built into the language.
If you have a script that consists of one 1500 character line with approximately 10 alphanumeric characters total, well written Perl examples aren't going to help you figure it out that much.
Sure, it will help if you're a complete newbie to Perl, and learning it from scratch. For those people, drilling good coding standards into them from day 1 is a GREAT thing, if for no other reason than to avoid the spaghetti that plagues a lot of Perl.
