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.

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.

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.

Isn't that a hash? Shouldn't python version be: dog['head']['ears'][0]['hairs'][123] ?

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.

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/{}/()/

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.

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.

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.

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.

I wasn't arguing that either way was better, just seeing the positives where negatives have been noted.

I personally haven't wasted anywhere near as much time with Python indentation compared to missing braces. I hated the whitespace thing at first, and it was only after going back to doing some Perl I noticed that the problem wasn't present in Python.

Though the fact that most other languages use braces is a pain, as it makes swapping between Python and Java / Perl / JavaScript / etc tricky, as I tend to get into the habit of using or not using semicolons at the end of a line.

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.

>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.

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.

>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.

Well if Explicit is better than implicit then this is one example of where Perl should be the preferred!

no snark, do you have a snippet you enjoy looking at in perl?

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.

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.

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.

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.

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

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.

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

2: https://metacpan.org/release/Path-Tiny

3: https://metacpan.org/release/Try-Tiny

4: https://metacpan.org/pod/Function::Parameters

5: https://metacpan.org/pod/Task::Kensho

I'll take a look at these, thanks. :)

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/Type::Tiny

Edit: Don't use Params::Validate; kbenson's recommendation for Function::Parameters looks awesome!

There is also Kavorka[1] as an alternative to Function::Parameters, which can use Type::Tiny types in signatures. The next step after that is Moops[2]...

[1] https://metacpan.org/pod/Kavorka

[2] https://metacpan.org/pod/Moops

You may be able to get them to update to at least 5.18.0 if you tell them about CVE 2013-1667 and all the mitigations added to 5.18.0 to prevent them.

https://duckduckgo.com/?q=CVE+2013-1667&ia=about

http://blog.booking.com/hardening-perls-hash-function.html

I would also recommend reading "Modern Perl" which is made available for free by the publisher/author at http://modernperlbooks.com/

( Also there are large codebases written in Perl ( I beleive booking.com is an example )

I also recommend installing the Perl you are using outside of the system directories. You may also find Pinto and https://Stratopan.com useful for managing your dependancies. Which is especially useful if you make your codebase modular.

I've written Python systems several tens of thousands of lines long. I don't think dynamicity has anything at all to do with a language's suitability for large projects (but if it did, I'd lean toward it making maintenance easier).

@tbrownaw... Do you mix Perl and Progress 4GL? Care to get in touch?

A little bit, yes. Contact info is in my profile now.

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.

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-u...