6 ms·

I don't think so. The real problem with Perl is it's an aesthetic train wreck. It is possible to write beautiful Python, Ruby, Erlang, ML, Prolog, C, C++ or eve

I don't think so. The real problem with Perl is it's an aesthetic train wreck. It is possible to write beautiful Python, Ruby, Erlang, ML, Prolog, C, C++ or even Java, but I challenge anyone to write a non-trivial Perl (5 or 6) program that doesn't make you feel slightly ill. Some of the semantics seem really nice, but the syntax is utterly disastrous.

nickysielicki 12y ago
I disagree, I mostly write perl for my job and I think that most of what I write is at least equally beautiful but generally more beautiful than equivalent python.
anom9999 12y ago
I hear this argument time and time again and it's simply FUD. Bad Perl is no different to bad C++ or any other language with a flexible syntax. But it's also the same visa versa. The problem with Perl is most times people are exposed to it, it's either from code golfing sessions were code is deliberately obfuscated; or when it's basically been used as a shell scripting language and thus often written by aging Perl hackers who don't care much for code cleanliness. And sometimes people just run away screaming because they simply don't understand all the regular expressions (but to approach Perl without an understanding of Regex is a little like trying to code Java without understanding classes then moaning about the weird surplus boilerplate code) I'm not trying to say that Perl doesn't have it's faults. It has a great many problems. But to state that Perls syntax makes it impossible to write clean code, is just a daft flamewar argument.
- crucini 12y ago
  Hmm. In python you have: dog.head.ears[0].hairs[123] In perl5 you have: $dog->{head}{ears}[0]{hairs}[123] I can see why some folks prefer the former.
  - viraptor 12y ago
    Isn't that a hash? Shouldn't python version be: dog['head']['ears'][0]['hairs'][123] ?
    - maratc 12y ago
      In both Perl and Python, "object" is a glorified hash, and its attributes are entries in that hash. Python just allows for a deeper level of syntactic sugar.
      - deleted 12y ago
        [deleted]
      - pwr22 12y ago
        In Perl a hash is any scalar value blessed into a class In modern Perl the attibutes would be accessed through accessors so the original example needs tr/{}/()/
  - esaym 12y ago
    I can't stand the '.' syntax. Someone that doesn't know python would have no idea if those are method calls or what. And in both cases, that is terrible code. Use a class or something...goodness.
    - coldtea 12y ago
      >I can't stand the '.' syntax. Someone that doesn't know python would have no idea if those are method calls or what. How is what someone who DOESN'T know Python would think relevant? That said, after even the smallest familiarity with the language, he sees that it's obviously not method calls unless it ends in (). Someone who doesn't know Lisp also doesn't know what (foo 4 2) or (quote foo 4 2) is.
      - FreezerburnV 12y ago
        I'm going to disagree with you: as someone who has worked in an extensive Python codebase, based on the snippet above, I have zero clue what is actually going on. Those could just be attributes in the object, or they could be properties with arbitrarily complex code to calculate the resulting object. It could be the same object, or a freshly-allocated object, or an object that exists already. The index operator could be on a list, dictionary, or custom class with, again, arbitrarily complex code. All of that code could even be written in pure C for all I know! That single line of code could be a rats nest of a thousand lines of Python, or C, or both. And that's not even getting started with the possibility of metaprogramming or creating new classes by wrapping an existing class at runtime. Saying that the snippet is obviously not using method calls is naive. Python is too flexible and allows programmers to do too many clever things for that, all hidden under "nice" syntax. EDIT: Forgot a case for what that code could be doing: it could be accessing a module with globals.
      - esaym 12y ago
        >How is what someone who DOESN'T know Python would think relevant? Because most of the people that complain about Perl don't know it either. I have no problem reading perl code of any kind (because I know it). Perl is a beautiful language IMHO.
  - anom9999 12y ago
    Perl's pseudo-objects are, in my opinion, one of the weakest aspects of Perl. So I'm not going to disagree with you that many other languages do that one thing better. But it's not always appropriate to nest your objects that deeply anyway (in any language, that can quickly become a mess). In my personal opinion, I prefer C-style braces over whitespace formatted blocks. Which means I find reading function and iteration blocks much easier to read in Perl than I do in Python. I'm not saying one is "better" than the other, but just offering a counter argument for how subjective language aesthetics really is.
    - collyw 12y ago
      Just to counter your points, having done many years of Perl, and now a Python. Perls OOP does feel like a bit of a hack. But it does make it transparent how everything works. I learned Java at University, and everything OOP was a black box and I had no real understanding of how it worked. After learning the Perl way, its really obvious what is going on because it is so transparent. Your current object doesn't have a method? Just look along the @ISA array until you find an object that does have it. Pythons whitespace is a pain at first, but having used it for a few years, one problem I do not miss is loosing a brace, when reorganizing blocks of code. You cut a few lines of code and paste it somewhere above or below, and your IDE shows you you are missing a brace somewhere. The indentation looks fine, so you can't see where it is. The whitespace thing is worth it to get rid of that problem alone.
      - kbenson 12y ago
        Aren't there just as many problems with cutting and pasting python and getting either slightly off indentation or mixed spaces/tabs? If the IDE fixes the problem, I don't see why it's any different for braces as it is for whitespace. There's easy ways to identify both.
        anom9999 12y ago
        Exactly. Arguing that one is better than the other is like arguing over which colour the best. Which is why I get so utterly sick of Perl being compared with Python - they are all going to have their strengths and weaknesses so at the end of the day, the "better" language / syntax boils down to personal preference.
  - draegtun 12y ago
    Well if Explicit is better than implicit then this is one example of where Perl should be the preferred!
- rtpg 12y ago
  no snark, do you have a snippet you enjoy looking at in perl?
MadcapJake 12y ago
Perl 6 has lots of syntactic breadth with all the sigils, twigils, operators, composers, etc. But I feel that, as with Ruby, all the sugar really helps after you've finally made it past the initial WHUUUT? phase. Just takes a bit longer than some languages :P
tbrownaw 12y ago
The only thing I don't like about Perl, is that it's a dynamic language and therefore unsuitable for large (as in, significantly longer than will fit on the screen at one time) programs. But "use strict;" helps with that, and apparently more recent versions (work has 5.8.8) allow subroutines to more easily declare a specific number of arguments. I'm actually learning more of it right now, so I can clean up and modularize some of my scripts. Because my other options (ksh93, Progress 4GL, and maybe older versions of Java or C++) are even less suitable.
- kbenson 12y ago
  If you haven't already, I highly suggest looking on metacpan.org for modules, and searching for highly rated[1] and recent ones. Things like Path::Tiny[2], Try::Tiny[3] and Function::Parameters[4] can make a huge difference in productivity and readability. Task::Kensho[5] is also useful for getting a good base set of medern modules to choose from for many tasks. 1: https://metacpan.org/favorite/leaderboard https://metacpan.org/favorite/leaderboard 2: https://metacpan.org/release/Path-Tiny https://metacpan.org/release/Path-Tiny 3: https://metacpan.org/release/Try-Tiny https://metacpan.org/release/Try-Tiny 4: https://metacpan.org/pod/Function::Parameters https://metacpan.org/pod/Function::Parameters 5: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho
  - tbrownaw 12y ago
    I'll take a look at these, thanks. :)
- muraiki 12y ago
  If you planned on using objects, you can consider using Moo for roles to allow composition, and combining it with Types::Tiny for type validation. There's also Params::Validate for plain functions. The validation is unfortunately at runtime, but at least you get a clear error instead of unanticipated behavior. Moo (and it's bigger parent, Moose) can really help you structure your application better using roles. https://metacpan.org/pod/Moo https://metacpan.org/pod/Moo https://metacpan.org/pod/Type::Tiny https://metacpan.org/pod/Type::Tiny Edit: Don't use Params::Validate; kbenson's recommendation for Function::Parameters looks awesome!
vinkelhake 12y ago
A long time ago I worked on a stock trading system written mostly in Perl. That code may have been a lot of things, but ugly wasn't one of them. So, it's definitely possible to write non-trivial Perl programs without feeling ill.
nevdka 12y ago
I work with perl every day, and couldn't disagree with you more. The language is flexible enough to be anywhere from damned ugly to blessedly beautiful. Much of the uglyiness can come from trying to write code for another language in perl syntax. Perl lets you write code that looks live Java, or C, or many other languages, but it usually ends up looking ugly. I see a lot of this. But when you write perlish perl, especially using modern features of the language, then... yeah. It can look as beautiful as any other language.
- muraiki 12y ago
  When I first started writing perl professionally, I kept trying to write things in a lispy functional style, which only made a mess. While it's true that There Is More Than One Way To Do It, there's still such a thing as "perlish perl" and by adopting this style I ended up writing some very pleasant and easy to read code.
bane 12y ago
I used to work mostly in Perl. It's true that it can easily be turned into an obfuscated mess. But I've also written some of the most maintainable code I've ever seen in my career in Perl. One project in particular was over 30k lines long (which in non-Perl languages must be worth millions of lines of code ;). It was put aside for a few years (4 or 5 IIR), then I had to return to it to do some maintenance and inside of an hour was able to digest the code-base, make the needed changes, test and release. Sloppy code and poor design infects every language. Perl does make it easy, but that's because Perl has a design emphasis on one-off scripts in the same way Java has an emphasis on large-team collaboration, and write-once run-once is what makes Perl so absurdly productive. Just like with any language, you set some code standards and some overall design principles and you can write really maintainable code in Perl. My wife has a similar story, after learning some basic Perl, she waded into a 100k line Perl codebase and in a couple days refactored some memory intensive code to use cheaper data-structures in a memory intensive part of the code. It was no-big-deal, but that's because the original team had left things well documented and wrote along sane standards.
Crito 12y ago
Are there any open source examples of beautiful C++? I don't doubt that it can exist, but I've never seen any. Maybe "beautiful for C++", but not "beautiful". For that matter, ditto for Java. Ideal Java code seems to be "not notable", rather than "beautiful". At its best, it is clean and clear but unexciting, like a Honda Civic.
zby 12y ago
The culprit of the 'ugly Perl' meme is the $ character, all the rest is just a rationalisation of the first impression: http://perlalchemy.blogspot.com/2011/01/is-responsible-for-ugliness-of-perl.html http://perlalchemy.blogspot.com/2011/01/is-responsible-for-u...

nickysielicki 12y ago

I disagree, I mostly write perl for my job and I think that most of what I write is at least equally beautiful but generally more beautiful than equivalent python.

anom9999 12y ago

I hear this argument time and time again and it's simply FUD. Bad Perl is no different to bad C++ or any other language with a flexible syntax. But it's also the same visa versa. The problem with Perl is most times people are exposed to it, it's either from code golfing sessions were code is deliberately obfuscated; or when it's basically been used as a shell scripting language and thus often written by aging Perl hackers who don't care much for code cleanliness. And sometimes people just run away screaming because they simply don't understand all the regular expressions (but to approach Perl without an understanding of Regex is a little like trying to code Java without understanding classes then moaning about the weird surplus boilerplate code) I'm not trying to say that Perl doesn't have it's faults. It has a great many problems. But to state that Perls syntax makes it impossible to write clean code, is just a daft flamewar argument.

crucini 12y ago
Hmm. In python you have: dog.head.ears[0].hairs[123] In perl5 you have: $dog->{head}{ears}[0]{hairs}[123] I can see why some folks prefer the former.
- viraptor 12y ago
  Isn't that a hash? Shouldn't python version be: dog['head']['ears'][0]['hairs'][123] ?
  - maratc 12y ago
    In both Perl and Python, "object" is a glorified hash, and its attributes are entries in that hash. Python just allows for a deeper level of syntactic sugar.
    - deleted 12y ago
      [deleted]
    - pwr22 12y ago
      In Perl a hash is any scalar value blessed into a class In modern Perl the attibutes would be accessed through accessors so the original example needs tr/{}/()/
- esaym 12y ago
  I can't stand the '.' syntax. Someone that doesn't know python would have no idea if those are method calls or what. And in both cases, that is terrible code. Use a class or something...goodness.
  - coldtea 12y ago
    >I can't stand the '.' syntax. Someone that doesn't know python would have no idea if those are method calls or what. How is what someone who DOESN'T know Python would think relevant? That said, after even the smallest familiarity with the language, he sees that it's obviously not method calls unless it ends in (). Someone who doesn't know Lisp also doesn't know what (foo 4 2) or (quote foo 4 2) is.
    - FreezerburnV 12y ago
      I'm going to disagree with you: as someone who has worked in an extensive Python codebase, based on the snippet above, I have zero clue what is actually going on. Those could just be attributes in the object, or they could be properties with arbitrarily complex code to calculate the resulting object. It could be the same object, or a freshly-allocated object, or an object that exists already. The index operator could be on a list, dictionary, or custom class with, again, arbitrarily complex code. All of that code could even be written in pure C for all I know! That single line of code could be a rats nest of a thousand lines of Python, or C, or both. And that's not even getting started with the possibility of metaprogramming or creating new classes by wrapping an existing class at runtime. Saying that the snippet is obviously not using method calls is naive. Python is too flexible and allows programmers to do too many clever things for that, all hidden under "nice" syntax. EDIT: Forgot a case for what that code could be doing: it could be accessing a module with globals.
    - esaym 12y ago
      >How is what someone who DOESN'T know Python would think relevant? Because most of the people that complain about Perl don't know it either. I have no problem reading perl code of any kind (because I know it). Perl is a beautiful language IMHO.
- anom9999 12y ago
  Perl's pseudo-objects are, in my opinion, one of the weakest aspects of Perl. So I'm not going to disagree with you that many other languages do that one thing better. But it's not always appropriate to nest your objects that deeply anyway (in any language, that can quickly become a mess). In my personal opinion, I prefer C-style braces over whitespace formatted blocks. Which means I find reading function and iteration blocks much easier to read in Perl than I do in Python. I'm not saying one is "better" than the other, but just offering a counter argument for how subjective language aesthetics really is.
  - collyw 12y ago
    Just to counter your points, having done many years of Perl, and now a Python. Perls OOP does feel like a bit of a hack. But it does make it transparent how everything works. I learned Java at University, and everything OOP was a black box and I had no real understanding of how it worked. After learning the Perl way, its really obvious what is going on because it is so transparent. Your current object doesn't have a method? Just look along the @ISA array until you find an object that does have it. Pythons whitespace is a pain at first, but having used it for a few years, one problem I do not miss is loosing a brace, when reorganizing blocks of code. You cut a few lines of code and paste it somewhere above or below, and your IDE shows you you are missing a brace somewhere. The indentation looks fine, so you can't see where it is. The whitespace thing is worth it to get rid of that problem alone.
    - kbenson 12y ago
      Aren't there just as many problems with cutting and pasting python and getting either slightly off indentation or mixed spaces/tabs? If the IDE fixes the problem, I don't see why it's any different for braces as it is for whitespace. There's easy ways to identify both.
      - anom9999 12y ago
        Exactly. Arguing that one is better than the other is like arguing over which colour the best. Which is why I get so utterly sick of Perl being compared with Python - they are all going to have their strengths and weaknesses so at the end of the day, the "better" language / syntax boils down to personal preference.
- draegtun 12y ago
  Well if Explicit is better than implicit then this is one example of where Perl should be the preferred!
rtpg 12y ago
no snark, do you have a snippet you enjoy looking at in perl?

MadcapJake 12y ago

Perl 6 has lots of syntactic breadth with all the sigils, twigils, operators, composers, etc. But I feel that, as with Ruby, all the sugar really helps after you've finally made it past the initial WHUUUT? phase. Just takes a bit longer than some languages :P

tbrownaw 12y ago

The only thing I don't like about Perl, is that it's a dynamic language and therefore unsuitable for large (as in, significantly longer than will fit on the screen at one time) programs. But "use strict;" helps with that, and apparently more recent versions (work has 5.8.8) allow subroutines to more easily declare a specific number of arguments. I'm actually learning more of it right now, so I can clean up and modularize some of my scripts. Because my other options (ksh93, Progress 4GL, and maybe older versions of Java or C++) are even less suitable.

kbenson 12y ago
If you haven't already, I highly suggest looking on metacpan.org for modules, and searching for highly rated[1] and recent ones. Things like Path::Tiny[2], Try::Tiny[3] and Function::Parameters[4] can make a huge difference in productivity and readability. Task::Kensho[5] is also useful for getting a good base set of medern modules to choose from for many tasks. 1: https://metacpan.org/favorite/leaderboard https://metacpan.org/favorite/leaderboard 2: https://metacpan.org/release/Path-Tiny https://metacpan.org/release/Path-Tiny 3: https://metacpan.org/release/Try-Tiny https://metacpan.org/release/Try-Tiny 4: https://metacpan.org/pod/Function::Parameters https://metacpan.org/pod/Function::Parameters 5: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho
- tbrownaw 12y ago
  I'll take a look at these, thanks. :)
muraiki 12y ago
If you planned on using objects, you can consider using Moo for roles to allow composition, and combining it with Types::Tiny for type validation. There's also Params::Validate for plain functions. The validation is unfortunately at runtime, but at least you get a clear error instead of unanticipated behavior. Moo (and it's bigger parent, Moose) can really help you structure your application better using roles. https://metacpan.org/pod/Moo https://metacpan.org/pod/Moo https://metacpan.org/pod/Type::Tiny https://metacpan.org/pod/Type::Tiny Edit: Don't use Params::Validate; kbenson's recommendation for Function::Parameters looks awesome!

vinkelhake 12y ago

A long time ago I worked on a stock trading system written mostly in Perl. That code may have been a lot of things, but ugly wasn't one of them. So, it's definitely possible to write non-trivial Perl programs without feeling ill.

nevdka 12y ago

I work with perl every day, and couldn't disagree with you more. The language is flexible enough to be anywhere from damned ugly to blessedly beautiful. Much of the uglyiness can come from trying to write code for another language in perl syntax. Perl lets you write code that looks live Java, or C, or many other languages, but it usually ends up looking ugly. I see a lot of this. But when you write perlish perl, especially using modern features of the language, then... yeah. It can look as beautiful as any other language.

muraiki 12y ago
When I first started writing perl professionally, I kept trying to write things in a lispy functional style, which only made a mess. While it's true that There Is More Than One Way To Do It, there's still such a thing as "perlish perl" and by adopting this style I ended up writing some very pleasant and easy to read code.

bane 12y ago

I used to work mostly in Perl. It's true that it can easily be turned into an obfuscated mess. But I've also written some of the most maintainable code I've ever seen in my career in Perl. One project in particular was over 30k lines long (which in non-Perl languages must be worth millions of lines of code ;). It was put aside for a few years (4 or 5 IIR), then I had to return to it to do some maintenance and inside of an hour was able to digest the code-base, make the needed changes, test and release. Sloppy code and poor design infects every language. Perl does make it easy, but that's because Perl has a design emphasis on one-off scripts in the same way Java has an emphasis on large-team collaboration, and write-once run-once is what makes Perl so absurdly productive. Just like with any language, you set some code standards and some overall design principles and you can write really maintainable code in Perl. My wife has a similar story, after learning some basic Perl, she waded into a 100k line Perl codebase and in a couple days refactored some memory intensive code to use cheaper data-structures in a memory intensive part of the code. It was no-big-deal, but that's because the original team had left things well documented and wrote along sane standards.

Crito 12y ago

Are there any open source examples of beautiful C++? I don't doubt that it can exist, but I've never seen any. Maybe "beautiful for C++", but not "beautiful". For that matter, ditto for Java. Ideal Java code seems to be "not notable", rather than "beautiful". At its best, it is clean and clear but unexciting, like a Honda Civic.

zby 12y ago

The culprit of the 'ugly Perl' meme is the $ character, all the rest is just a rationalisation of the first impression: http://perlalchemy.blogspot.com/2011/01/is-responsible-for-ugliness-of-perl.html http://perlalchemy.blogspot.com/2011/01/is-responsible-for-u...