8 ms·

So why is Perl so unfashionable? He mentions OO and readability, but if Perl has "one of the most featureful object systems in existence", does that leave just

by ryanf 16y ago

So why is Perl so unfashionable? He mentions OO and readability, but if Perl has "one of the most featureful object systems in existence", does that leave just readability? I'm curious (as someone who knows very little about Perl) what the actual reasons are for Python and Ruby having stolen so much of Perl's thunder.

Lewisham 16y ago
It is pretty much the OO and readability. I worked with Perl for years, and, much to my shame, I really didn't understand a lot of many of the CPAN modules I relied upon. I read the poddoc and then copied the syntax they used and edited to my needs. Perl provides many, many different ways to achieve the same thing. This is somewhat by design, in the idea that Perl should match your own intuitive style. But most people's styles are not yours, and it becomes impenetrable. IMHO Ruby's strength over Perl is the much stronger OO, Python's strength is the focus on "there is only one way to do it", which lets most people be able to grok most of your code. I couldn't go back to Perl by choice now. I first jumped to Python just to get some sense of clarity in my life, but now I prefer Ruby due to how its extreme openness means there are some really awesome gems out there.
- wazoox 16y ago
  > Python's strength is the focus on "there is only one way > to do it", which lets most people be able to grok most of > your code. Unfortunately this is not my way of doing it, and that's why I'll always prefer Perl to Python.
  - sigzero 16y ago
    That is so true. There really is never "only one way to do it" because Programmers think differently.
    - stcredzero 16y ago
      In other words, coding standards are always useful.
- rikthevik 16y ago
  I'd say Python's strength is "explicit is better than implicit." There's usually not too much magic going on.
  - elblanco 16y ago
    I really have to agree with this. The Python community has really embraced clarity of code and style as a core principle of the language, while Perl has embraced a more..."do it how you want" philosophy. It's a bit like the subtle philosophical differences between two dialects of the same language, say Received English and an inner-city slang.
- rbonvall 16y ago
  It always get cited as "only one way to do it", but the actual motto is "there should be one obvious way to do it". It's very different.
  - JadeNB 16y ago
    I think that the full quote is a synthesis of the two: > There should be one-- and preferably only one --obvious way to do it. The follow-up I think hammers home the subjectiveness of ‘obvious’: > Although that way may not be obvious at first unless you're Dutch.
rjbond3rd 16y ago
They are all good languages splitting the same market (roughly). Perl lets you get under the hood in a way that either is frowned upon, impractical, or prohibited in other languages. So there's a language for every temperament now. For example, in Perl, [if you wanted to], you can roll your own object system. That makes some people happy, and other people uncomfortable. But much of Perl has moved on to one very cool object system, Moose. The Tim Bray article reads as if he's unaware of Modern Perl and all the Perl 6 stuff which has been back-ported to Perl 5. In all honesty, I had to check the date because the article had a 2002 feel to it.
- pyre 16y ago
  One thing that people fail to mention when hyping Moose is that there is a start-up penalty for using it. You can lessen this penalty by not using all of the whiz-bang features of the object system, but that kind of defeats the purpose, no? [ This doesn't really matter much for long-running scripts or controllers in a webapp, but it does for a lot of other applications ]
  - draegtun 16y ago
    http://news.ycombinator.com/item?id=1513929 http://news.ycombinator.com/item?id=1513929
  - rjbond3rd 16y ago
    Just use Mouse, a lighter Moose. Or use Any::Mouse (whichever is installed).
- rjurney 16y ago
  Comments like this seem to miss the point: use strict; use warnings; is not required. Moose is not the default object system. You can't say, "Oh, this library has that feature!" Thats not good enough. It has to be built-in, not optional, core to the language. If you're working by yourself - you can write code in any language well. In groups, that is NOT the case. Writing Perl in groups requires rigorous code reviews and cooperation, and even then nightmares are hard to avoid. Expressiveness has its downsides. You cannot simply bring a Perl noob onto a project and not have him ruin it. You CAN bring a new Rubyist onto a project and they can be productive.
Natsu 16y ago
My take is that the other languages simply supply more structure for how to do things, while Perl leaves you free to do things any which way. Sometimes, that freedom is invaluable. But for some people, that freedom means that they have to work to supply the structure on their own. In short, I think some people feel that there are too many ways to do it. Anyhow, that said, I think that people are too quick to write Perl off. Some of us are still writing Perl. Maybe I'm not doing anything big or fancy, but it's all documented, readable, and every single script on my computer uses warnings and strict. If you compare Perl to duck tape, I'd be like McGuyver: always keeping a roll of it in my pocket.
expeditious 16y ago
One thing is that Perl 5 doesn't include by default a number of modern features that Python and Ruby have OOTB. Easy OOP, exceptions, and named function args, to name a few. If you want these things for Perl, you need to dash out to the corner store (the CPAN) for them. Also, Perl 5 tends to be used for a lot of unglamorous admin work. So, although almost everyone's got a few utilities or cron tasks on their system written in Perl, they're not shouting about it from the rooftops. Also, Python is an easy language to learn, and so people like to learn it and blog about how easy/nice/shiny it is: http://xkcd.com/353/ http://xkcd.com/353/ .
- telemachos 16y ago
  Ruby doesn't provide named function arguments. In my experience, Rubyists tend to do what Perlers do: use hashes to create quasi-named arguments to functions.
elblanco 16y ago
I think a lot of it has to do with the language, when written very idiomatically, tends to rapidly become hard to maintain. Part of this perhaps is the history of Perl as a fantastic one-off tool language (I'm not a developer for my company, I have other responsibilities, but when we need a fast one-off tool for some data processing, the C++, C, Java, Python and Ruby guys all come to me to hack off something to just get the job done because I can do it in a few minutes vs their half a day). I've looked back at some of those one-offs, and for the life of me I can't tell what they are supposed to do. On the other hand, I have written some largish projects in Perl, and when I constrained myself to a very explicit dialect of the language (almost Javaish in verbosenss), I found it to run fast, and be highly maintainable. I cracked the code open to a 20k line project I wrote 4 years ago and was able to jump right in. In that respect it's a bit like C++ in that you can write code to be unreadable or you can write it to be readable if you constrain yourself to a non-idiomatic subset of the language. But unfortunately, the Perl community tried to embrace and open attitude towards this (there's more than one way to do things) that ultimately ended up embracing the "get it done now and in as few lines as possible" idiomatic unreadable code style. I think other than that, OO is an important factor, Perl's OO system was so hard to do right, and other languages OO just seemed to embedded and clean to work with, but also Perl has not really found itself (for some reason) in many embedded systems, in GUI programming, on client-side systems (e.g. Javascript), etc. all places where it could have done well, but for whatever reason just never found a good comfort zone the way it does for sysadmin type tasks (and a few very small domains like computational linguistics). The Perl community seems to have spent a decade endlessly spinning around the drain of supporting backend work, and never approached the more sexy applications of the language.

by ryanf 16y ago

Lewisham 16y ago

It is pretty much the OO and readability. I worked with Perl for years, and, much to my shame, I really didn't understand a lot of many of the CPAN modules I relied upon. I read the poddoc and then copied the syntax they used and edited to my needs. Perl provides many, many different ways to achieve the same thing. This is somewhat by design, in the idea that Perl should match your own intuitive style. But most people's styles are not yours, and it becomes impenetrable. IMHO Ruby's strength over Perl is the much stronger OO, Python's strength is the focus on "there is only one way to do it", which lets most people be able to grok most of your code. I couldn't go back to Perl by choice now. I first jumped to Python just to get some sense of clarity in my life, but now I prefer Ruby due to how its extreme openness means there are some really awesome gems out there.

wazoox 16y ago
> Python's strength is the focus on "there is only one way > to do it", which lets most people be able to grok most of > your code. Unfortunately this is not my way of doing it, and that's why I'll always prefer Perl to Python.
- sigzero 16y ago
  That is so true. There really is never "only one way to do it" because Programmers think differently.
  - stcredzero 16y ago
    In other words, coding standards are always useful.
rikthevik 16y ago
I'd say Python's strength is "explicit is better than implicit." There's usually not too much magic going on.
- elblanco 16y ago
  I really have to agree with this. The Python community has really embraced clarity of code and style as a core principle of the language, while Perl has embraced a more..."do it how you want" philosophy. It's a bit like the subtle philosophical differences between two dialects of the same language, say Received English and an inner-city slang.
rbonvall 16y ago
It always get cited as "only one way to do it", but the actual motto is "there should be one obvious way to do it". It's very different.
- JadeNB 16y ago
  I think that the full quote is a synthesis of the two: > There should be one-- and preferably only one --obvious way to do it. The follow-up I think hammers home the subjectiveness of ‘obvious’: > Although that way may not be obvious at first unless you're Dutch.

rjbond3rd 16y ago

They are all good languages splitting the same market (roughly). Perl lets you get under the hood in a way that either is frowned upon, impractical, or prohibited in other languages. So there's a language for every temperament now. For example, in Perl, [if you wanted to], you can roll your own object system. That makes some people happy, and other people uncomfortable. But much of Perl has moved on to one very cool object system, Moose. The Tim Bray article reads as if he's unaware of Modern Perl and all the Perl 6 stuff which has been back-ported to Perl 5. In all honesty, I had to check the date because the article had a 2002 feel to it.

pyre 16y ago
One thing that people fail to mention when hyping Moose is that there is a start-up penalty for using it. You can lessen this penalty by not using all of the whiz-bang features of the object system, but that kind of defeats the purpose, no? [ This doesn't really matter much for long-running scripts or controllers in a webapp, but it does for a lot of other applications ]
- draegtun 16y ago
  http://news.ycombinator.com/item?id=1513929 http://news.ycombinator.com/item?id=1513929
- rjbond3rd 16y ago
  Just use Mouse, a lighter Moose. Or use Any::Mouse (whichever is installed).
rjurney 16y ago
Comments like this seem to miss the point: use strict; use warnings; is not required. Moose is not the default object system. You can't say, "Oh, this library has that feature!" Thats not good enough. It has to be built-in, not optional, core to the language. If you're working by yourself - you can write code in any language well. In groups, that is NOT the case. Writing Perl in groups requires rigorous code reviews and cooperation, and even then nightmares are hard to avoid. Expressiveness has its downsides. You cannot simply bring a Perl noob onto a project and not have him ruin it. You CAN bring a new Rubyist onto a project and they can be productive.

Natsu 16y ago

My take is that the other languages simply supply more structure for how to do things, while Perl leaves you free to do things any which way. Sometimes, that freedom is invaluable. But for some people, that freedom means that they have to work to supply the structure on their own. In short, I think some people feel that there are too many ways to do it. Anyhow, that said, I think that people are too quick to write Perl off. Some of us are still writing Perl. Maybe I'm not doing anything big or fancy, but it's all documented, readable, and every single script on my computer uses warnings and strict. If you compare Perl to duck tape, I'd be like McGuyver: always keeping a roll of it in my pocket.

expeditious 16y ago

One thing is that Perl 5 doesn't include by default a number of modern features that Python and Ruby have OOTB. Easy OOP, exceptions, and named function args, to name a few. If you want these things for Perl, you need to dash out to the corner store (the CPAN) for them. Also, Perl 5 tends to be used for a lot of unglamorous admin work. So, although almost everyone's got a few utilities or cron tasks on their system written in Perl, they're not shouting about it from the rooftops. Also, Python is an easy language to learn, and so people like to learn it and blog about how easy/nice/shiny it is: http://xkcd.com/353/ http://xkcd.com/353/ .

telemachos 16y ago
Ruby doesn't provide named function arguments. In my experience, Rubyists tend to do what Perlers do: use hashes to create quasi-named arguments to functions.

elblanco 16y ago

I think a lot of it has to do with the language, when written very idiomatically, tends to rapidly become hard to maintain. Part of this perhaps is the history of Perl as a fantastic one-off tool language (I'm not a developer for my company, I have other responsibilities, but when we need a fast one-off tool for some data processing, the C++, C, Java, Python and Ruby guys all come to me to hack off something to just get the job done because I can do it in a few minutes vs their half a day). I've looked back at some of those one-offs, and for the life of me I can't tell what they are supposed to do. On the other hand, I have written some largish projects in Perl, and when I constrained myself to a very explicit dialect of the language (almost Javaish in verbosenss), I found it to run fast, and be highly maintainable. I cracked the code open to a 20k line project I wrote 4 years ago and was able to jump right in. In that respect it's a bit like C++ in that you can write code to be unreadable or you can write it to be readable if you constrain yourself to a non-idiomatic subset of the language. But unfortunately, the Perl community tried to embrace and open attitude towards this (there's more than one way to do things) that ultimately ended up embracing the "get it done now and in as few lines as possible" idiomatic unreadable code style. I think other than that, OO is an important factor, Perl's OO system was so hard to do right, and other languages OO just seemed to embedded and clean to work with, but also Perl has not really found itself (for some reason) in many embedded systems, in GUI programming, on client-side systems (e.g. Javascript), etc. all places where it could have done well, but for whatever reason just never found a good comfort zone the way it does for sysadmin type tasks (and a few very small domains like computational linguistics). The Perl community seems to have spent a decade endlessly spinning around the drain of supporting backend work, and never approached the more sexy applications of the language.