Nope. just read this entire thread and you'll learn why.

I've read the entire thread and haven't discovered your why. I think the most insightful thing that appeared is the assertion that there isn't much overlap between HN folks and Perl types.

I keep turning to Perl. For the man pages. For the stuff in C-PAN. For the one-liner concision that obviates awk, sed, bash and the rest. I've learned much and gone far with many other things, but Perl keeps getting play with me. It continues to be the shortest distance between two things that no one else has ever had to connect. All the classic protocols have serviceable Perl implementations that have been mature since the late 90's. It's a special little programming language and I believe I'm going to continue pulling off little miracles with it when necessary. That's what it was designed to do and it's still fit for purpose as far as I'm concerned.

People think Perl code is unreadable and mysterious because the language design philosophy is different than other programming languages. Most languages strive for a limited, orthogonal set of built-ins and features without any repetition. Most languages enforce opinions about how things like OO and function calls are going to work.

Perl is designed to be maximally expressive. It is designed to be instantly familiar to someone who writes shell script, uses sed and/or awk and writes C for Unix environments. If you don't have this background, it can be a lot to absorb.

Here are some big things that Perl outsiders find troublesome at first glance:

1. Sigils are mysterious and scary--other languages don't have them. In practice, they're rather nice--they distinguish between functions and variables. They act sort of like a minimalist form of hungarian notation.

2. Built in regexes. Regex syntax is dense and messy. Putting it right in the language makes them easy to use. It also can make things hard to read. Perl didn't invent regexes and tt hasn't stopped most languages from implementing regex libraries. That's why Perl offers the expanded syntax that makes it easy to document complex regexes.

3. Special variables - $_, @_ are odd enough, but when add in the whole panoply from perlvar, it's pretty gross. In reality you really only need to know a few ($_, $@, @_, and $! are the only ones I use regularly), but they are terse and must simply be memorized.

4. Function calls in Perl are weird. Most people use one of the two common forms of argument unpacking that give you pass by copy semantics, but you can also pass by reference. Once you get the hang of it, it's not that complicated, but it is different and can be more than a little confusing for newbies.

5. List flattening. When you call a function like so: foo( @bar, %baz, $qux ), it gets one big list of arguments, the members of @bar and %baz get expanded. It's sort of the opposite of destructuring on assignment.

Ok i'll play. The reason is because it's unreadable. Yeah i'm sure you can write your perl program with ease and it can do all kinds of magical things. I believe you.

But the problem is it's one of the worst languages when it comes to readability.

I also used to write perl, especially doing natural language processing, etc. so I know pretty much what you are talking about in this department. But I would always find myself wondering what the hell i wrote 6 months ago when I used perl. That doesn't happen with other new languages I picked up along the way.

So if you're just a lone coder working on your own thing that no one else will use, then no one's stopping you. Go ahead. But if you're trying to maintain a large project with many developers, perl is very inefficient.

It's unreadable if you write it that way. It's a flexible language with a dozen ways to do most things, and some of those are more legible than others.

I use Python for a lot of the things I used to use Perl for, and one of the biggest benefits is that it constrains your style a lot more, and things look more consistently readable.

> It's unreadable if you write it that way. It's a flexible language with a dozen ways to do most things...

Yes, these are precisely the properties that makes Perl unreadable. This permissiveness is a weakness!

I personally don't use Perl much, but I've seen quite a few scripts written by members of my IT department that I could read top->bottom without any issue whatsoever.

I like Perl, but I can see the argument for why it's not readable. People often mistakenly use sections of code with crazy looking regexes as an example...that's not really the issue though.

To me, it's a combination of two things:

- The culture that it's good to have many ways to do the same thing.

- The abundance of sigils on variables ($, %, @, etc), and how that gets unmanageable once you have complex data structures. Especially once you mix in references.

Yeah that's because it's written by people from IT department. They are supposed to write it in the most readable manner since it's their job.

But like others on the thread said, the inherently extreme flexibility makes it hard to write a consistently readable code. You literally need some sort of discipline to consistently write a readable code.

I don't know why my parent comment gets so furiously downvoted.

As a Perl dev earning a living by doing web development in Perl, I am quite interested in the show stopping downsides of the language. I really have my skin in this game.

Not only have I read this thread, I've read the countless Perl bashing articles that keep appearing on the internet and the main complain is the syntax.

Indeed, one can write unreadable Perl but that is also possible with Python, Ruby and even brainfuck (if you can believe that).

I have to tell you this: in my over 10 years of being a paid programmer and over 7 years of being a 100% Perl dev, the syntax is the easiest thing to grasp.