Most of the anti-Perl comments I've heard have been from people who really didn't know it very well, if at all.
Some of them might have glanced at some Perl code and saw a dense regex and dismissed it as "line noise". Well, yeah, if you don't know regexes you would be forgiven for thinking it was line noise, but if you did know regexes it should look no more like line noise than a similarly dense regex in any other language.
For a long time now, Perl has allowed regexes to be commented. Commenting dense regexes and splitting them up in to short regexes assigned to judiciously named variables is just good style in any language, and has been the norm in Perl for a long time. Furthermore, modern Perl style guidelines advise code to be written with verbose, English words instead of ancient Perl one-character special variable names.
So setting aside both dense, uncommented regexes and ancient single-letter special variable names, both of which have been recognized as poor style in Perl for decades now, I'm really not sure what the complaints about Perl readability are about. To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.
If you include non-mainstream languages, some languages which have a lot of fans here on HN are arguably a lot less readable than Perl to someone only familiar with traditional Algol-style languages. In particular, I'm thinking of Forth and Haskell. Yet you rarely hear complaints on here about their readability.
It's what my company's entire code base is written in. So every hour of every work day for the past 6 months.
>To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.
It's no one thing, but a bunch of little things that compound on top of each other. Until you get something like this:
while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };
Mostly though it's how it's used. It can technically do anything, so a lot of the times it is asked to do everything. Until one day you wake up to find you have hundreds of perl files, all tens of thousands of lines long, that all interconnect in an insane Object Oriented hierarchy soup stretching across every conceivable programming space - from database control to money processing to security to web site design.
Saying that I see absolutely nothing wrong with that perl code you are highlighting as being obtuse or ugly. Anyone who understands Perl should not have an issue with that line. It is clear and concise.
There are a variety of things that Perl programmers would consider idiomatic (depending, I would say, on the background of the Perl programmer). Using something like (foo && bar) in this manner is actually quite common in some Perl code bases (although, I suspect it is more commonly used where there are multiple conditions that are chained -- Damian Conway's "Perl Best Practices" book has some examples of those).
In the example given, I suspect the author of that code did it that way to reduce the length and put it on one line. I understand the desire for concise code, but if it were me, I would spread it out more to make it easier to read (mostly, I just wouldn't put it all on one line). I like having concise code also, but there is a fairly definite line that I try not to cross. If I have to work hard at all to keep track of the pieces, it's time to either add some more whitespace (horizontally or vertically, or sometimes both), change some of the constructs, or add some temporary variables to make the intent clear.
I am the person most likely to have to deal with the code a year later, so like many others, I try to not confuse my future self.
That's a business culture thing. If you set the expectation, that it's okay to do that, people might do that. If you set the expectation that it's not okay, people shouldn't.
The equivalent C and Python are likely just as ugly (given that the equivalent python might be using a far too complex range statement or put it on a single line using : and ;, which is possible...).
That said, as bad code goes, that's not really that bad. The only non-standard things are <> and $_, and if you don't know what those are, you really haven't done the minimum of learning about the language (<> might be somewhat exotic in that form depending on the codebase, but $_ is not something you can get way with not knowing about). In all, the major problem with it is that it's not commented and uses poor variable names, which is something every language needs to deal with. I would write it like so if I wanted it on a single line (but I would probably use 2-3 lines):
# Report each duplicated line once
my (%lineseen,@linedups); # This was required in yours too right? I assume you're using strict...
while (<>) { (++$lineseen{$_}==2) && push(@linedups, $_); };
# Report duplicate lines once
my %lineseen;
my @linedups = grep { ++$lineseen{$_}==2 } (<>);
Some people will look at this as evidence that Perl should be relegated to one-liners, but I find immense usefulness in combining my more engineered aspects with one-liners, and providing myself with a "project evaluator". What I do is create a simple bash script which just calls perl and sets the library include path to the project lib, includes a few useful things to always have (Path::Tiny, Try::Tiny, Data::Dumper, etc), and passed the rest of the args to Perl. Using DBIx::Class for SQL manipulation and/or using complex API client libraries I've written combined with the abilities of perl to do things easily as a one-liner is amazing.
Still mostly fine so long as you know you're only dealing with 7-bit ASCII, IIRC, but Caveat Emptor.
It's easier to just say File::Slurp in mixed company so people immediately know what it is if they look it up, rather than them be confronted with a grab-bag of functions.
The specific example cited
while(<>){ $h{$_}++ && ... }
is quite understandable to anyone who has used Perl for more than a few weeks. Its a common pattern. Complaining about this, which is, for the uninitiated, looping over reading each line from STDIN until EOF, incrementing a hash variable indexed by each line, etc.
This is a very common pattern in perl. Draw your own conclusion as to whether complaining about idiomatic language from a "skilled practitioner" is something one should take without a grain or two of salt.
And of course, being Perl, there are many ... many ... ways to accomplish the same task. Leveraging CPAN modules. I'd leave discovering some of the as an exercise for the reader.
Who knew you could do that in a programming language? Not sure I would have ever thought to try.
I even love the above sample while loop, you can tell the person who posted it is good because they can't create too heinous an example. The <> and $_ provide what I think of as visual anchors that describe a path for the data to follow. Obviously some style minded author could do it better, but it's not bad. The real line noise is from the one-liners for systems tasks I think.
You should see C++ Templates! Even the idiomatic examples in cppreference.com will blow up your head and require multiple re-reads.
while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };
my @output-array = lines.unique; my @output-array = lines(:!chomp).unique;
We use Perl::Critic [0] to deal with issues like that. It has enabled us to develop a very consistent style, and helps new devs adopt to it quite quickly.
Indeed, I hope this thread gets picked up by http://n-gate.com/
Take time to really grok Perl and you may find the soundbite swipes at Perl don't make sense any longer.
I'm never sure what people don't like about OO Perl. There's a tiny bit of boilerplate in a constructor, other than that, it doesn't seem different from other OO script languages.
It's just another example of Perl's biggest strength and weakness. Total freedom to build something amazing or shoot yourself in the foot.
There's no private data or private methods in Python objects. All the properties are right there for anyone to read, protected only by convention.
JavaScript and Perl have almost exactly the same OO model, yet many people quite like JavaScript's OO, so that can't be it, surely...
There's no private data or private methods in JavaScript objects. All the properties are right there for anyone to read, protected only by convention.
(It's closer than it looks. Perl's "bless" function means almost the same as JavaScript's ".__proto__ =", and inside-out data hiding is possible in JavaScript much the same as Perl, although hardly anyone uses it in either language.)
I try to use OO sparingly when possible, and in Perl that generally just means I've been using a hash and decide it'd be more convenient that it keep some functions to itself rather than pass it around to other functions.
I will say in Perl's defense, the bare implementation really made me appreciate what OO actually is under the hood. I felt like I understood it much better, especially since it takes a mixed approach (rather than 'everything must be an object, including Program.cs' which I never really enjoyed).
But it is also one of the most writable language. In Perl, for most problems, there is a quick and dirty way of addressing it. It is especially true when it comes to processing text files, the thing that Perl is best known for.
Many languages try to be clean and consistent, it is obviously good for readability, but it means that choices have to be made. Sometimes the best way is the "wrong" way and you have to fight against the language. Perl solved that problem by not having a "wrong" way of doing things, screw cleanliness and consistency.
Also, first class regex are awesome for quick and dirty text processing.