4 ms·

I'm going to take a moment to vent about Perl. My company was experimenting with it as an alternative to Ruby based on the enormity of available CPAN modules.

I'm going to take a moment to vent about Perl. My company was experimenting with it as an alternative to Ruby based on the enormity of available CPAN modules. 1. CPAN is awful. The website itself is so bad that the "correct" way to browse it is to use the big brother "Metacpan". Metacpan is also very bad, they strayed too close to CPAN design. Navigating it is a pain, and most of the documentation is done very poorly because no one puts time into formatting their readmes. None of the modules are in github, the issue tracker is a nightmare, the links make no sense ( "Source (raw) Browse (raw)" ) - the website itself is poorly done. 2. CPAN has many modules, which sounds like a selling point. The truth is that many of the modules we have worked with have bugs and poor documentation, and almost all of them are unmaintained. The owners either gave up or actually died (this is an old language after all). There is absolutely no support for trying to do common tasks with CPAN modules. You can't Google for your error, you won't get a response on StackOverflow. Bug reports don't get answered because the ecosystem is a ghost town. This makes trying to do common tasks painful. 3. CPAN is just messy all around. There's not even a command line flag to find out what version of a module you have installed. You have to hack into its internals to figure out what versions you're running. Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror. A "benefit" of CPAN is that modules are tested against multiple architectures for you. The reality is that these tests don't matter. The Perl developers I've worked with bypass the tests with CPAN by installing with --notest because it's faster, and more than once a module has failed to install because the tests failed. But the failure was either a false positive or had no noticeable impact on implementation, and there's no alternative and no one to respond to bug reports. The only known benefit of CPAN - automated test running, has never once proved helpful. 4. One point I like in this article is that Python makes the right thing obvious. Perl's "multiple ways to do things" is one of its bigger design flaws. It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex. It's all to the detriment of the language. I have to Google for how to iterate over a hash every time, because there's multiple ways to do it, and they all suck. I never know if iterating over a $hash is the same as iterating over a %hash or a \%hash. Or if I should be searching for "hash" or "hashref" or if I should be using a "list" or an "array" or a scalar or who cares. The multiple ways to do things only amounts to one asshole on the team will exploit some unknown feature of map to write shorter code, not document it, and no one can read it. Any efficiency gained from shorter code is lost to unmaintainability. Also, Perl is not efficient, so it doesn't matter. 5. The language itself is gross. Beauty is subjective, readable code is not. The prefixing of variable names with @, % et all makes dissecting code hard and Googling impossible. The tacking-on of modern functionality will slap you in the face repeatedly. See: references. References are one of, if not the, biggest design flaw in Perl. They were introduced as a tack-on to hack over it's shitty default data structures. They make reading and writing code confusing, overly complicated, and haven not once offered us any benefit. Perl's leaky abstraction over poorly implemented data structures is easily seen in references. 6. No really, the language is gross. It has magic built in, and the syntax is a nightmare. Everything is done with sigils (characters like ~!=@#$ etc). You get function arguments as @_ . You do a regex match with $string =~ /(capture)/. This will magically populate $1 through $n with capture groups. This is bad. To substitute a string, you do $string =~ s/a/b. This modifies the string in place. Try to Google for how to not modify the string in place. Seriously, try and Google for it. If you forget to include an even number of values in a list it becomes another data structure entirely. If you don't put a '1;' at the end of your module code it will fail to work (no, really). 7. Larry's personal beliefs stray into Perl too much. Larry is a well known Christian, and you must "bless" a reference, a keyword baked into the language. This creeps me out. It doesn't really matter, and I 100% acknowledge how judgmental I'm being, but it still is out of place in a programming language. 8. All of these reasons culminate to one point I just realized: Perl is a bad language for a team. It might be fine for one person to write code that will never have to be maintained or read to accomplish some dirty task. The "features" of Perl ruin it for a team environment. Feautres like its "flexibility", wheel reinventing to avoid buggy CPAN modules, unreadable features hidden in sigils, magic, poor documentation, and hacker culture make it a very poor choice for multiple people to work on the same thing. This is the perspective of a relative newcomer (~3 months of Perl exploration). I'm not a Python advocate and I don't have a strong opinion of what other language you should use, but Perl has caused us many problems and we switched to Ruby early on because of them. Maybe if / when I learn more about it I'll have a different opinion of it. Right now though I agree with this article and seeing Perl go out the door is fine with me.

kbenson 13y ago
I can't help but think if perhaps you have decided to learn it, rather than explore it, maybe your opinion would be somewhat different. What I mean by that is that at first glance, Perl looks very similar to some other languages, but the difference in design philosophy means it often behaves in a different way than you would expect from Python, or even Ruby (which borrows quite heavily from Perl). I doubt you would jump into Lisp coming from C or Python without a good guide, because Lisp looks different. Perl doesn't necessarily "look different" (beyond sigils, but that's usually just waved away without thought), but it is different in many ways. In that respect, Perl can sometimes be harder to learn for someone who already has experience in other imperative languages, such as C or Python.
chromatic 13y ago
The only known benefit of CPAN - automated test running, has never once proved helpful. Your experience is so very different from mine (and that of everyone I know) that I'm not sure we're on the same planet. CPAN Testers provide near real time feedback on the patches made to Perl itself. That's the combined test suites of almost 130,000 modules for every commit to the Perl language and core libraries.
slashdotaccount 13y ago
Troll harder, greenhorn. (account "metsgrets" created 7 hours ago) > CPAN is awful […] Navigating it is a pain […] the issue tracker is a nightmare These are opinions. I cannot see any facts to substantiate the claims. > most of the documentation is done very poorly because no one puts time into formatting their readmes No, most of the documentation is the best among libraries in any programming language because everyone uses documentation templates and then fills in the details in copious amount. These templates have been honed over years, and the docs are regularly quality checked by automated services. It also helps that the documentation format POD is so so stupidly simple that it never gets in the way of work: a programmer spends all the time writing content, none on formatting. > None of the modules are in github All of the modules are in Github. > the links make no sense ( "Source (raw) Browse (raw)" ) "Source" shows the module's source (HTML, syntax highlighted). "Browse" browses the directory structure of the unpacked distribution. The raw links are the plain text equivalents served by the API primarily for programmatic access. All of this is readily obvious by just following a link. > many of the modules we have worked with have bugs and poor documentation Unsubstantiated, no details. > and almost all of them are unmaintained CPAN freshness tells a different story. > owners either gave up or actually died There's a process in place for taking over maintenance. It is used a couple of times a month. > There is absolutely no support for trying to do common tasks with CPAN modules Wrong. Any common task has several modules. > You can't Google for your error Unsubstantiated, no details. > you won't get a response on StackOverflow Wrong. Unanswered quota is only 10%. > CPAN is just messy all around Same is true for any file archive. Show me a programming language where this is not the case. At least it's centralised, not strewn across the Web! On top of the archive, curated indexes such as http://p3rl.org/Task::Kensho http://p3rl.org/Task::Kensho exist. > There's not even a command line flag to find out what version of a module you have installed. You have to hack into its internals to figure out what versions you're running. Wrong. $ pmvers Catalyst 5.90060 $ perl -MCatalyst -E'say Catalyst->VERSION' 5.90060 > Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror. Then pick a mirror near you. http://mirrors.cpan.org/ http://mirrors.cpan.org/ The standard CPAN client does this automatically during first run. > The only known benefit of CPAN - automated test running, has never once proved helpful. Unsubstantiated, no details. > It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex. Wrong, this is because humans have different ways to think and preferences how to express themselves. The programming language works with the grain of the human mindset, not against it. http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt > I have to Google for how to iterate over a hash every time, because there's multiple ways to do it, and they all suck. I never know if iterating over a $hash is the same as iterating over a %hash or a \%hash. Then you know less than a beginner in his third lesson. ⎆ my %hash = qw(a b c d); my $hash = \%hash ⎆ while (my ($key, $value) = each $hash) { say "$key => $value" } a => b c => d ⎆ while (my ($key, $value) = each %hash) { say "$key => $value" } a => b c => d ⎆ while (my ($key, $value) = each \%hash) { say "$key => $value" } a => b c => d > if I should be searching for "hash" or "hashref" or if I should be using a "list" or an "array" or a scalar or who cares Only bash and Tcl free you from thinking about and selecting the appropriate data type. > The multiple ways to do things only amounts to one asshole on the team will exploit some unknown feature of map to write shorter code, not document it, and no one can read it. This is a social problem, and not the responsibility of the programming language or its designer. Anyone can write crap code in any language. Enforce code style and policy locally. Static analysis tools like http://p3rl.org/perlcritic http://p3rl.org/perlcritic exist. Apply them. > Perl is not efficient Perl remains the fastest of the scripting languages. > Beauty is subjective, readable code is not. Unreadable code is a social problem across all programming languages. This has nothing to do with Perl per se. > The prefixing of variable names with @, % et all makes dissecting code hard Wrong, sigils make the nouns stand out, just like capitalisation in written German. Both empirically make reading faster and comprehension easier. > Googling impossible Wrong. It is true that search engines drop sigil characters from the query, but the context words still find the result in the index. > References are one of, if not the, biggest design flaw in Perl […] make reading and writing code confusing, overly complicated Unsubstantiated, no details. > haven not once offered us any benefit Wrong, as references are the basis for objects (OOP). > the language is gross. It has magic built in, and the syntax is a nightmare Unsubstantiated, no details. > You get function arguments as @_ Concept stolen from Shell, already remedied in version 20. Signatures have been available for years with modules. > You do a regex match with $string =~ /(capture)/. This will magically populate $1 through $n with capture groups. This is bad. Agreed, side effects are evil. That's the legacy interface and impossible to deprecate/remove. The expression will also return a list of the captures which you can then assign or mangle as you wish. my @results = $string =~ /(capture)/ Good style dictates to prefer this interface. > $string =~ s/a/b. This modifies the string in place. Try to Google for how to not modify the string in place. Seriously, try and Google for it. Yes, and? g perl substitute return modification (Type it out to see Google suggestion/autocompletion.) First five results all teach: my $new = $string =~ s/a/b/r > If you forget to include an even number of values in a list it becomes another data structure entirely. Wrong, a list is a list no matter how many elements. > If you don't put a '1;' at the end of your module code it will fail to work (no, really). Valid complaint. Again, it's too late to fix it because existing code needs to keep working, back-compat is serious business for perl5-porters. New projects with modern Perl just avoid the need for that last line: http://p3rl.org/true http://p3rl.org/true > bless […] but it still is out of place in a programming language. The word is religion neutral. Your biases show. > The "features" of Perl ruin it for a team environment. Unsubstantiated, no details.

kbenson 13y ago

I can't help but think if perhaps you have decided to learn it, rather than explore it, maybe your opinion would be somewhat different. What I mean by that is that at first glance, Perl looks very similar to some other languages, but the difference in design philosophy means it often behaves in a different way than you would expect from Python, or even Ruby (which borrows quite heavily from Perl). I doubt you would jump into Lisp coming from C or Python without a good guide, because Lisp looks different. Perl doesn't necessarily "look different" (beyond sigils, but that's usually just waved away without thought), but it is different in many ways. In that respect, Perl can sometimes be harder to learn for someone who already has experience in other imperative languages, such as C or Python.

chromatic 13y ago

The only known benefit of CPAN - automated test running, has never once proved helpful. Your experience is so very different from mine (and that of everyone I know) that I'm not sure we're on the same planet. CPAN Testers provide near real time feedback on the patches made to Perl itself. That's the combined test suites of almost 130,000 modules for every commit to the Perl language and core libraries.

slashdotaccount 13y ago

Troll harder, greenhorn. (account "metsgrets" created 7 hours ago) > CPAN is awful […] Navigating it is a pain […] the issue tracker is a nightmare These are opinions. I cannot see any facts to substantiate the claims. > most of the documentation is done very poorly because no one puts time into formatting their readmes No, most of the documentation is the best among libraries in any programming language because everyone uses documentation templates and then fills in the details in copious amount. These templates have been honed over years, and the docs are regularly quality checked by automated services. It also helps that the documentation format POD is so so stupidly simple that it never gets in the way of work: a programmer spends all the time writing content, none on formatting. > None of the modules are in github All of the modules are in Github. > the links make no sense ( "Source (raw) Browse (raw)" ) "Source" shows the module's source (HTML, syntax highlighted). "Browse" browses the directory structure of the unpacked distribution. The raw links are the plain text equivalents served by the API primarily for programmatic access. All of this is readily obvious by just following a link. > many of the modules we have worked with have bugs and poor documentation Unsubstantiated, no details. > and almost all of them are unmaintained CPAN freshness tells a different story. > owners either gave up or actually died There's a process in place for taking over maintenance. It is used a couple of times a month. > There is absolutely no support for trying to do common tasks with CPAN modules Wrong. Any common task has several modules. > You can't Google for your error Unsubstantiated, no details. > you won't get a response on StackOverflow Wrong. Unanswered quota is only 10%. > CPAN is just messy all around Same is true for any file archive. Show me a programming language where this is not the case. At least it's centralised, not strewn across the Web! On top of the archive, curated indexes such as http://p3rl.org/Task::Kensho http://p3rl.org/Task::Kensho exist. > There's not even a command line flag to find out what version of a module you have installed. You have to hack into its internals to figure out what versions you're running. Wrong. $ pmvers Catalyst 5.90060 $ perl -MCatalyst -E'say Catalyst->VERSION' 5.90060 > Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror. Then pick a mirror near you. http://mirrors.cpan.org/ http://mirrors.cpan.org/ The standard CPAN client does this automatically during first run. > The only known benefit of CPAN - automated test running, has never once proved helpful. Unsubstantiated, no details. > It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex. Wrong, this is because humans have different ways to think and preferences how to express themselves. The programming language works with the grain of the human mindset, not against it. http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt > I have to Google for how to iterate over a hash every time, because there's multiple ways to do it, and they all suck. I never know if iterating over a $hash is the same as iterating over a %hash or a \%hash. Then you know less than a beginner in his third lesson. ⎆ my %hash = qw(a b c d); my $hash = \%hash ⎆ while (my ($key, $value) = each $hash) { say "$key => $value" } a => b c => d ⎆ while (my ($key, $value) = each %hash) { say "$key => $value" } a => b c => d ⎆ while (my ($key, $value) = each \%hash) { say "$key => $value" } a => b c => d > if I should be searching for "hash" or "hashref" or if I should be using a "list" or an "array" or a scalar or who cares Only bash and Tcl free you from thinking about and selecting the appropriate data type. > The multiple ways to do things only amounts to one asshole on the team will exploit some unknown feature of map to write shorter code, not document it, and no one can read it. This is a social problem, and not the responsibility of the programming language or its designer. Anyone can write crap code in any language. Enforce code style and policy locally. Static analysis tools like http://p3rl.org/perlcritic http://p3rl.org/perlcritic exist. Apply them. > Perl is not efficient Perl remains the fastest of the scripting languages. > Beauty is subjective, readable code is not. Unreadable code is a social problem across all programming languages. This has nothing to do with Perl per se. > The prefixing of variable names with @, % et all makes dissecting code hard Wrong, sigils make the nouns stand out, just like capitalisation in written German. Both empirically make reading faster and comprehension easier. > Googling impossible Wrong. It is true that search engines drop sigil characters from the query, but the context words still find the result in the index. > References are one of, if not the, biggest design flaw in Perl […] make reading and writing code confusing, overly complicated Unsubstantiated, no details. > haven not once offered us any benefit Wrong, as references are the basis for objects (OOP). > the language is gross. It has magic built in, and the syntax is a nightmare Unsubstantiated, no details. > You get function arguments as @_ Concept stolen from Shell, already remedied in version 20. Signatures have been available for years with modules. > You do a regex match with $string =~ /(capture)/. This will magically populate $1 through $n with capture groups. This is bad. Agreed, side effects are evil. That's the legacy interface and impossible to deprecate/remove. The expression will also return a list of the captures which you can then assign or mangle as you wish. my @results = $string =~ /(capture)/ Good style dictates to prefer this interface. > $string =~ s/a/b. This modifies the string in place. Try to Google for how to not modify the string in place. Seriously, try and Google for it. Yes, and? g perl substitute return modification (Type it out to see Google suggestion/autocompletion.) First five results all teach: my $new = $string =~ s/a/b/r > If you forget to include an even number of values in a list it becomes another data structure entirely. Wrong, a list is a list no matter how many elements. > If you don't put a '1;' at the end of your module code it will fail to work (no, really). Valid complaint. Again, it's too late to fix it because existing code needs to keep working, back-compat is serious business for perl5-porters. New projects with modern Perl just avoid the need for that last line: http://p3rl.org/true http://p3rl.org/true > bless […] but it still is out of place in a programming language. The word is religion neutral. Your biases show. > The "features" of Perl ruin it for a team environment. Unsubstantiated, no details.