I've found over the past decade or so that when I write a "perl" program I'm really writing about five lines of glue code around multiple CPAN packages. Well maybe more than 5 lines for control flow, some business-logic error handling, etc.
When I write in another language I spend a long time looking for a library like the ten I'd find in CPAN, sometimes I find one but often enough not, then a long time complaining about how if I used perl I'd have access to the perfect CPAN module and therefore already be done with the whole project, then basically reimplement the CPAN module in the smaller inferior language, then finally write glue logic to link stuff together.
I never fail to be amazed when I see pages and pages of an inadequate homemade xml parser written in an inferior language or maybe a blizzard of regex, and then hearing bragging about how in Perl the elegant alternative language code would closely resemble line noise. No, in Perl, those pages and pages of buggy code would instead closely resemble one line: "use XML::Simple;" Repeat a zillion times over.
My "perl" programs / systems actually shrink in length over time rather than expanding, which is unusual in smaller languages.
CPAN might be centralized, but Java libraries are far superior. This is not a pissing contest, but a fact. The java runtime makes everything else look amateurish and unprepared. Debugging, profiling, introspection and distribution, all built into the platform. Attach to any running process and analyze away. Perl is good when it works, but when it doesn't, it's cryptic stack traces and `exit -1`, nothing meaningful.
This is not a pissing contest ... but calling it a fact is also silly.
Perl has integrated debugging. Perl has pluggable runops so profilers can be attached to the platform (e.g. Devel::NYTProf). Distribution == CPAN and the 'make dist' system from ExtUtils::MakeMaker, again built in.
The introspection is -different-, perhaps, but I'm not sure I'd say it's better or worse.
Nothing meaningful? You set it to break into the debugger when that exception is thrown, and then debug it. I'm honestly not sure how this is any different an experience to in java - any java application not actively being debugged will write a stack trace to its log file and either exit or move on to the next request too, no?
Not really true. Yesterday I was trying to debug resource-loading issues. In any normal programming language, you can just strace it and you'll see where the program is doing I/O and you can figure out where it's trying to load files from. But if everything is in a jar, you don't see any OS-level I/O happening when Java tries to load something, so you have to invent all-new tools just to figure things out. When you switch to Java you throw away 40 years of UNIX for a bunch of private methods implemented by summer interns at Sun 20 years ago. The third-party libraries are fine, but the core is not.
I never used strace even when doing C and sometimes C++ and still managed. Eclipse can't be beaten for Java, C/C++, PHP, Perl, Ruby and Python development.
EDIT: I just used "strace /usr/bin/java -jar myjar.jar" and saw what looks IO but I'm not familiar with strace output yet. It looks like a handy utility though. Can you give an example of something that you expected to see but didn't when you tried it?
While Java has many problems, I don't consider packages to be a wrong choice necessarily. Not all good choices will be introspectable with unix-y tools (like mmaping a vm's state into memory).
Wow, that's cool! Thanks for sharing that. Does Perl also have something similar to Python's "import pdb; pdb.set_trace()", which lets you drop into a debugger at a predefined location in your code? I've been finding that really helpful.
Knowing Perl, it probably is possible, and I just never learned about it.
When I was at Google, the opinion among some of the SREs I knew was that Java there was better than elsewhere so you actually did get reasonable debugging stack traces, but the C++ libraries there were still significantly easier to debug problems in than the Java ones.
Yes, I know that those AbstractFactoryFactories let you produce convenient higher order abstractions, but when things go pear shaped, they can make it really hard to figure out what was supposed to be happening, let alone where it went wrong.
AbstractFactoryFactory nothing--maybe Google's sensible enough not to use frameworks which create bytecode and inject it into running processes, but try to debug something configured via annotations or XML sometime.
Half the point of CPAN is "installability", it is trivial to d/l and install lots of modules. There is also CPAN Testing which drastically helps portability. Can Java really compete with a Perl module that has a long list of dependencies (50+ is a pain but will work) and some code tying it together...? [That was the example in the GP post.]
With all due respect to the Java runtime (if not its memory use :-( ), it is part of a totally different ecosystem compared to the usual suspects of the scripting languages.
(And I'd argue that it is always easier to debug a scripting language than C/C++/Java, except maybe just for long running server processes.)
"Can Java really compete with a Perl module that has a long list of dependencies (50+ is a pain but will work) and some code tying it together...? "
Maven does it. I'm pretty sure that all main languages have their equivalents too.
Even when I don't code in perl, when I get stuck and find there are no pre-built libraries in the language I'm using, I find myself going to CPAN... "Lets see how they did this in perl..."
I've got an interesting relationship with perl. My first exposure was back in the 80's when I was at Sun and perl was, to my taste, a shell scripting language with the complexity of APL and the readability of Forth. I hated it.
When I took the job at Blekko they said "We do most of our stuff in perl" and I was dubious about that.
However, now that I've been exposed to V5 for a couple of years and have probably written a few thousand lines of code in it, I find its easier to write a quick hack in than Python, and it certainly has a better 'command line' feel than Java. But it wasn't until I started coding up a quick CMS type gizmo for making HTML pages that I truly "got" the power of CPAN backing it up. There is a lot of stuff there. Folks like me who gave up on the language in the V3/V4 days as "hopelessly hacky" should re-visit it.
Before i switched to Python as my general purpose language, i used to be a bit of a Perl fanatic.
I've still to come across a language that lets you get your ideas down as quickly. It's full of fantastic time savers, e.g. the for(<>) construct and the format output functionality cover a bunch of common use cases in minimal keystrokes (let me pipe in some data, analyse it, then spit it out in a clean report).
It can hurt readability but for small one offs, it often doesn't matter.
My experience is almost exactly the opposite. Whenever I'm writing in Python I can't escape the feeling that the code is simply fragile due to missing language features. Obviously this starts with all the regex initializations (often quite distant in source from where they are applied) which make regular expressions in python just a huge mess.
Perl's autovification allows me to build a data structure at parse time with code that is trivially verifiable. Python forces me to sprinkle the code with a thousand tests for whether or not the field is initialized yet, or write extra code to define things like defaultdict instances (with syntax that I always have to look up, and which in my experience most python programmers don't understand).
Not to mention that if I want to use an OO syntax for that data structure I have to write extra code defining a class for it (and inevitably be yelled at by the pythonista security branch for all the __whatnot__ methods I forgot to define).
Python's comprehension/generator syntax is nice, though, and doesn't have a clean analog in perl. One thing it does do well is chaining up "filter" operations on aggregate data structures in a clean way. And that has value and is worth emulating. But honestly most of the rest of the language is junk compared to perl or ruby.
I agree with you about the feeling of fragility, especially with defaultdicts.
As for regexes - while they are somewhat clumsy in python, they don't have to be defined distantly:
m = re.match(r'(\d{4})', buf)
if m:
print "year: %s" % m.group(1)
The only thing that really bothers me about the above is the need to separate the assignment of m from the test.
Re comprehensions: seems to me they are just Python's version of Perl's map and grep.
grep:
@good = grep { $_->{width} > 9 } @crates;
good = [c for c in crates if c['width'] > 9]
map:
@squares = map { $_ * $_ } @nums;
squares = [i*i for i in nums]
Which is better? I think Ruby's way is the best, and Perl/Python are a wash here.
Now, on the autovivification note, I wonder if we can make a Python class that has the desired behaviors. Like:
c = PerlishStruct()
c['foo'][17]['bar'] = 'baz'
You don't really think it's junk, do you? Perl, Python and Ruby are extremely similar; I'd say Perl's more ergonomic, but messier; Python's cleaner, but sometimes awkward, and Ruby pretty much has the best of both worlds.
You probably shouldn't do this in an inner loop: :-)
m = re.match(r'(\d{4})', buf)
'map' is more general than just the single, convoluted statement of list comprehensions, which really seems as a kludge from unwillingness to accept multi-line lambdas. So something new was invented that had to be learned; then it was argued it is a boon. (Like references in Perl. :-) )
(There is some defaultdict functionality for autovivification in Python iirc.)
Yeah, they are all similar. I don't know enough Ruby to have an opinion.
And then there are a pile of modules that implement python-style generators, some using https://metacpan.org/module/Coro (co-routines implemented as threads), some using crazy hacks:
Yeah, honestly though those fail the "clean" test for me. What I really meant isn't the computational capabilities of python generators but the way the mesh nicely with the way builtins like "in" or "all()" or "any()" work on plain old data. Reasoning about them, in general, isn't any harder than reasoning about a dict or list in the common case, and that's a feature missing from the perl equivalents which try to do it in a library. I'd feel comfortable throwing a comprehension into code intended to be maintained by a novice. I'd never inflict any of that junk on the poor maintainer.
I'm in a similar boat. I've largely switched to Python as my scripting language (except for one-liners), but I'll still defend Perl against those who dismiss it out of hand. After using it an Amazon, I've seen firsthand how productive one can be with the language; and, if you're careful (following, e.g., the guidelines in "Perl Best Practices" by Conway) it's very possible to write maintainable code as well.
I hear you on the one-liners issue. Python is unhelpful when it gets to that - there are no -n, -p, -l switches or special variables like there are in Perl and Ruby.
It's a shame really, since all the building blocks needed to implement a useful mode for writing one-liners are there. In fact, I have a work in progress module that tries to address this issue: https://github.com/gvalkov/python-oneliner
This is an interesting idea, but if you need an extremely terse DSL which doesn't look anything like Python and has to be learned anew,
why not just use Perl directly? Maybe for environments where you can't install Perl?
Thanks. My approach is actually pretty minimal. Just a read-print-loop (-n, -p), a few local variables (equivalents of $_, $~, $. etc) and a shorthand import syntax to take away some of the verbosity. There are other projects, such as pyp[1], that are more ambitious, but put you through a learning process.
By all means, everybody should use what they are comfortable with. Ruby and Perl allow you to write extremely terse and awesome one-liners, the likes of which will never be possible in Python. But if the first solution that pops into your head is a Python one, why not use that?
I'm actually the reverse. I went to perl from python. I usually use it for system scripting and what I like about it is that it replaces bash nicely without removing the power of specialized syntax. I find it much easier to type open("program -args |") than to construct a subprocess object in python and manually extract lines from its output. On the other hand, python is pretty handy for larger programs, more than a few screens of dense perl syntax starts getting hard on the eyes.
J, now there's a language! The C source is written in a J like style: a wall of ascii punctuation interspersed with single char identifiers.
It looks like a fantastically expressive language, but i fear the learning curve would be too steep for my time invested to pay off - others would have to spend the same time to learn it as well, negating any code sharing / reuse in my org (we don't use J).
I found others i had to share code with weren't as interested as me about writing maintainable perl code - i got really fed up with a patch work of "write only" perl scripts performing useful functions in prod. From DB maintenance tasks to general housekeeping, to work-arounds for prod app issues that never got prioritised for strategic fixes.
I found in practice python code produced by most others was easier maintained: it seemed to more or less force people to write more readable and therefore, maintainable code.
I also viewed the fact that Python was one of the premier languages across so many problem domains (Systems, DB, GUI, Web, Large data, GPU, etc.) as being a sure fire payoff for any time invested in it.
In environments this size it's not any one persons actions dictate what becomes the status quo: different groups will have different agendas and therefore priorities and views. I guess i was lucky that everyone else was either willing to give Python a go, or was easily convinced.
FWIW over the past few years it's proven to be a good choice for us. There are still O'Reilly books float about, esp between the newcomers but there's no zealous "where's my camel book!" shouts anymore.
So one of perl's nicest features is it just plain, flat gets out of your way. If you want to write something some way, go ahead, perl will allow you.
This is great - you can cook something up in 5 lines that would take 15+ in Python and 50+ in C++. It also means that it's really tempting for some to abuse this ability, even for code which will be long lived.
I'm not sure I understand how that answers my question. Are you suggesting that Python doesn't get out of your way and that somehow its intransigence provides the benefit of somehow forcing people to write more readable code?
I don't believe Python is that inflexible (it's not), and I don't see how the limited and superficial ways in which Python pushes all code to look the same are really that meaningful.
Interesting how I consider Perl an 'old' language, and the others new languages. I guess it says more about how revolutionary Perl was at the time and how quickly it became widespread. The only other language I know of that went from 0 to everywhere in under 5 years was Javascript.
It would be interesting to know if anything older than Fortran 77 is still in active use. I know that there is a lot of F77 still around, but the Fortran code I've seen at NASA is at least up to F90/F95. Someone who learned F95 or later and never wrote fixed format Fortran would be pretty lost if they had to work on F77 or, Backus forbid, F66. C, on the other hand, has changed much less, beyond the ANSI function declarations. I first used the C version that was in 6th Edition AT&T UNIX and that had some features that would look strange to modern users, such as initializers not using = signs:
int i 4;
and the assignment operators being the other way round:
a =+ 2;
The point is, when discussing the age of a language, how important is the degree of change over time? At what point is it a new language? The same is true of human languages. I can understand Shakespeare with little trouble, but I miss some points unless there are footnotes. I can get a bit of Chaucer, but far from full comprehension. Beowulf? Not a prayer. But it's all "English"...
People still run production COBOL programs, today, that were written in the 60s and 70s. They may compile it with a version of COBOL that has support for features like object oriented programming. But the programs were written decades ago, and do not use those features.
I know one person who, 10 years ago, went back to work for the same company that she had worked at 30 years prior. Among other things she found a PL/I program that not only was around, but the last commit on was hers. She asked them, "I'm the last person to touch that, and I don't even know that language any more! Why are you still running it?" The answer was, "It never broke." (Sadly that company went bankrupt in the financial crisis, so her code is probably now dead.)
A few years back, we bought a commercial address processing/validation library to use with .NET. I noticed it had a dependency on the .NET Fujitsu COBOL runtime. So even newer development might pull in COBOL code without even knowing it.
> It would be interesting to know if anything older than Fortran 77 is still in active use.
In active use, that's actually easy, especially in the industrial space (that's why I mentioned distributed as well as active, which gives another metric entirely)
Just about a year ago I was tasked with recovering software from a HP1000/RTE machine (driving an industrial oven in a forge), written in a Fortran dating back from before it was properly standardized.
We recovered the code through the machine's serial port, with the built in print functionality, which conveniently prepended a header along with the file's content. Together with pyserial at the other end, a few hours of hacking had a laptop listen via a PL2302 serial/USB adapter, parsed the printed header to get filename and a few metadata, and wrote content to the proper location.
The harder part was manually moving through directories, and printing the files at 1200 baud, through a terribly laggy and completely burned out 80x23 passive monitor.
Headers in the code mentioned it was actually older than me.
With a few massaging, the code actually compiled on a recent gfortran (F95!), but hte linking part was entirely different, and many proprietary symbols were missing. We went through the 30 years old documentation and found what we needed to stub them and plan how to act forward. The thing was actually quite close already to Unix and what we find on Linux these days, only much much more primitive. The code contained critical functions whose role was to compute thermal data for automation, according to various (thermodynamic and other) complex and undocumented rules, so I built a detailed plan about possible actions to take, including linking to C wrappers binding the stuff into Python, complete with a prototypal HTML5 visual status feedback of the automation system. That's when I left the project (and the job).
Ya, I have no clue either. Pascal was the first language I was originally taught (though I had been messing with QuickBasic for a few years before that). Pascal seemed to have died out in the late 90's.
Lisp was invented 54 years ago. The Common Lisp standard is the capstone on an unusually long and fractured history of development. Fortunately many of those good ideas have trickled down over the decades, making mainstream languages steadily less terrible, and competing proprietary implementations are no longer commonplace.
FORTRAN is the oldest language that is still used today. If you consider the Lisp dialects together as a single language, then Lisp would be a close second.
Scheme, for example, is a decade older than Common Lisp, but it's still commonly considered a Lisp (no pun intended).
Counting the years from the time the languages entered the spotlight might be a better metric of age. Even though Python is only four years younger than Perl, it feels so much newer because it spent more time 'in the oven'.
I'd peg Python's coming of age around 2001, although I could be wrong about that. Ruby is even fresher out of the oven, not really reaching the limelight until 2006.
I interviewed you once ... approximately forever ago ... and you told me at the time you were just switching to using Ruby for fun stuff, while using Perl for work. I'm glad you switched back, and appreciate your excellent CPAN modules!
Perl Kit, Version 1.0
Copyright (c) 1987, Larry Wall
You may copy the perl kit in whole or in part as long
as you don't try to make money off it,
or pretend that you wrote it.
Slightly self-promotion, but you can get a variety of old perl sources at http://www.etla.org/retroperl/ (collected by someone non-me, I can't remember who though)
I had thought someone had done a perl 1 release that built on modern systems, but on a quick hunt I can't find it.
The stats in the link are interesting. I recently discovered the Code::Statistics module (https://metacpan.org/module/Code::Statistics). It tells you the cyclomatic complexity of your code which wikipedia tells me is basically the number of possible paths through your code.
It might be fun to see that run against the Perl core.
I also like looking at the number of lines of code. If your features go up while complexity and lines of code go down -- that could be a good sign.
Came here looking for someone else wishing Perl many happy returns as it reaches this august landmark.
I have been working as a programmer for 25 years and started using Perl in 1993 or so. I cannot express what it felt like to have this incredibly powerful tool that seemed to integrate all of the sed, awk, shell, and C code that I had for research. Using Perl absolutely felt like magic, particularly for analyzing text.
I love Python, Ruby, and Lua too, but Perl will always be the tool that quickly gets things up and running.
I believe most mainstream languages used for web development are quite old now. And today it is matter of personal taste to choose one over another one unless you are constrained by coding standards.
To me Perl is awesome :) Too bad I do PHP for a living, but I still enjoy it when doing something for myself. Like last time I learned about web framework Mojolicious ( http://mojocasts.com/ ) and built http://gotldr.com and http://hntldr.com leveraging Mojolicious and Redis - https://github.com/hippich/perl-tldrer . It took me few evenings, but I really enjoyed tinkering it.
I haven't written a single line of Perl for over a year now and can't remember much of the language - and I am sure I would not even be able to understand my own code anymore!
Perl is a very handy and powerful scripting language but it should not be considered as a durable solution. Whatever is quickly hacked using Perl should be probably rewritten in a much more structure language, especially if you plan on maintaining this code.
Of course one can also write perl with care and attention. Perl::Critic, the Moose family, and appropriate use of the CPAN really helps with that discipline.
It's interesting to me how often people cite "Unicode in code" as some sort of amazing thing. I once posted on S.O. about the idea that maybe we should have a programming language where the vast array of options in Unicode were exploited to make things like Regular Expressions more readable (avoiding the backslash plague alone would be worth it).
I got smacked down by people complaining that they didn't know how to type anything but ASCII.
Jokes tend to get downvoted on HN and there's been a few (to many) jokes in this HN post :( Your's the only one I didn't downvote because decided to leave a comment instead.
Did get the point of your comment, are you are trying to convey that you have problems with the Perl philosophy- "There is more than one way to do it(TIMTOWTDI)"?
You have chosen a very small topic to discuss the vast range of advantages TIMTOWDI offers.
Now bear with me for a minute while I explain you this whole thing.
Have you worked with a language where your though tool just wasn't for you? Have you felt that language was pushing down its own self believed principles down your throat? What happens when programmers face such situations? They just leave the tool and go to something else. Perl is one of those few tools that adapts to the programmer, rather than expecting the programmer adapt to it.
Now like every other design choices you can ever make, it has its own tradeoffs. Being flexible, adaptive, powerful and quick to evolve means at times you have to sacrifice a little consistency. You can sure present your arguments and your design perspective against it, but your design again will have its own trade offs.
Why so many different ways of doing things? For example why do we have something like 'map' and 'foreach' in Perl? You won't understand this when you have used and written code that leverages these keywords to their power. Its more or less like explaining why Ice cream is delicious to somebody who has never eaten it. Unless you taste it yourself won't truly understand.
Perl is quick to learn. You can learn as much Perl to do the kind of work you can do in Python/Java/whatever. But as you learn more Perl, you become productive at solving problems. You can do it quickly, with succinct code with more powerful syntactical features.
If you know enough about the standard Perl warn() and die(), it turns out:
croak(): (slang) To die[1]
confess(): to provide information, commonly[2] as one is dying[3]
carp(): To complain, often at length and of minor details[4]
cluck(): Not actually sure about this one, although 'clucking their disapproval' seems to be something of an english idiom.
So yeah, there's some logic to the choices, even if it is rather whimsical. It's a valid point to say it's not immediately obvious, but it doesn't take long (from experience) to figure what they do and out which one you want for a given situation.
I don't get what the issue is, I don't even know Perl and it seems pretty straightforward to me: Carp is a library with a set of mnemonic assertion functions for libraries to signal usage errors committed by their callers.
Do people just prefer one function with a bunch of fiddly little enums or something?
A bit of a kneejerk reaction admittedly, but historically any post about Perl on reddit or HN garners reactions proclaiming how perl is entirely dead and how Python is objectively infinitely superior.
I am afraid Python fans have a history of trolling Perl. Pick up any Perl thread and you will see enough examples of Python people trying to forcing their principles down your throat, even if there is absolutely no context to mention it.
Hate is an emotional response that humans have ... how can you tell if the comment was trolling or simply a visceral response?
I don't hate Perl (I first learned CGI programming with it), but I do think there are better ways to write maintainable, enterprise scale software. There are two main problems with Perl (as I see it): 1) The language is so permissive that it allows newbs to write bad code but still obtain results. Habits, both good and bad are learned! 2) Perl experts seem to delight in writing code that's "tricky" (for lack of a better word). It's like a contest to see who can wring the most out of one 80-character line of code and it leads to mid-to-low functioning Perl programmers being confused.
The modern perl5 production platform is mostly made up of modules built and maintained to intentionally make people -not- go 'wtf?' all the time.
Modern Perl and other recent books push people towards developing good habits.
The current generation of experts tend to either put our tricky in very well encapsulated CPAN modules, or comment the hell out of it, or both ... or if at all possible, stick it into a paste site somewhere for other people to go "whee!" at and do something sensible in the main codebase.
Your complaints about perl were absolutely valid a decade ago ... these days there's still some truth to them, but we've grown up a lot since then :)
I am a perl lover. For me, the TIMTOWTDI means mainly that I can write code the way I think. When I have an idea of a solution for a problem, I have no effort to make to translate this idea into perl because there exists always a concise syntax for it. Perl does not limit your thinking. Instead of loosing time fighting to adapt your mind to the language, you have freedom to improve your skills. The more you improves, the more you find cases where not common syntaxes appear to be useful. At the end, when you are an experienced perl programmer, you master most of the syntax "tricks" used by the others experienced perl programmers.
Hmmm ... I have found the same feeling with every language I've mastered. I never did master Perl but even if I had, I would have set it aside like most of the other languages that I have mastered when a compelling new language/tool/system came out. I try not to form an emotional relationship with my tools as it might adversely limit my adaptability.
Try Java. Java has its merits, but they mostly revolve around defending you from hundreds of current and former coworkers, not merging your mind with the machine the way Perl does.
>> The language is so permissive that it allows newbs to write bad code but still obtain results
How is this different than any other language? You can write bad code in any language. Perl might allow for more obfuscated code which really makes it harder to read - but that again reflects on the programmer - not the language. Take a look at a code in PHP, Python, C, or any language written by "newbs" and you will see poor practices used everywhere.
>> The language is so permissive that it allows newbs to write bad code but still obtain results
I can't see any relevance for a professional choice if newbies can shoot bigger holes in their foot with a certain tool.
That is a natural result of a powerful tool.
>> Perl experts seem to delight
Anecdotal. Ten years old description of half humorous use (and exercises). Also very different from best practices even then -- and especially different from how many/most work today.
Let me also note: If Perl wasn't better in many ways, you trolls would make serious arguments instead of "experts seem to delight"... [Or as you wrote above "Twenty-five years already? Now it can retire with full benefits."]
But I'll bite a little. Perl has the best OO system of all the scripting languages (Moose). The CPAN is the gold standard for scripting languages (and probably everything else). The testing culture is afaik second to none. The same goes for Unicode support. And so on.
I think there's a valid argument in the fact that it's diverse enough that you could have 2 highly experienced Perl coders who nevertheless disagree about an awful lot of things[1].
In professional environments or large projects, hopefully you're got a reasonably comprehensive style guides (or better yet, perlcritic config), but for smaller things, it can be a bit of a struggle to understand and conform to the specific style in question if you're trying to contribute to something new.
I don't think it's enough of an argument to dismiss the language though, and agree that the benefits far outweigh the somewhat-pointy learning curve.
[1] The old "Everyone uses 10% of C++, but they all have a different 10%" joke, basically.
I am not posting this to bag on Perl, but just to show its fingerprint. If you find that periodic table to be funny or cool then you are a lot more likely to be happy with Perl than if it makes you shudder.
I do find it funny, but also, it's [perl 6] documentation. But I agree with your point that personal preference varies.
Just an anecdote: a startup I work with built a product on Rails 2. It has been successful beyond anyone's wildest dreams. But they have a huge mess on their hands now, and it was caused by -success- :)
You claim to really not be aware that table is for a quite different language -- Perl 6?
That point has been made many, many times.
Edit: To the cultural question, there might be a point. I might add that I don't know Perl 6, but it seems like an insane amount of cool/fun toys (macro language like lisp with an Algol-like syntax?! If they can pull that off it is incredible.) That might say something about me and Perl people. But people I admire use both vim and Windows, so I'm not certain.
I also think Perl 6 has some really cool and innovative ideas. Far from using it to smear Perl, I think it is more interesting than previous versions.
But you are in denial if you think that this chart isn't a reasonably representative cultural artifact of the Perl community and the Perl aesthetic. Perl 5 is not exactly poor in operators, and it is the same core community which produced both.
I don't think that Perl is bad. I am saying that Perl is very strongly what it is. And while some people won't like that aesthetic, I don't see why anyone should apologize for it.
I never claimed that Perl wasn't powerful ... in fact I think I stated the opposite. Where I work, Perl is the lingua franca of the ops team and they certainly get things done. But the newbies don't shoot holes in their foot ... they blow it clear off and often don't survive.
My comment above may be perceived as a bit trollish but I was also thinking about "thanking Perl for a job well done". I quit Perl for what I consider valid reasons (which you completely dismiss - My experience may be "anecdotal" to you, but it's still my experience) which you're clearly not going to agree with. But notice that I never said "you shouldn't use it". I'll even admit that some people accomplish a lot with it ... and that CPAN is almost the gold standard for everything (with the exception of Maven Central I think).
So keep using Perl if you want ... but hopefully now you'll understand those of us that will no longer use it and why it's popularity is declining (http://www.tiobe.com/index.php/content/paperinfo/tpci/index....). I expect I'll replace my current tools with something better (more productive/safer/maintainable) in the next 5 years since that's been a continuing pattern for me. What will you be using in 5, 10, 15 or 20 years?
Newbies writing code for things like (say) fiddling with directory trees should absolutely be writing unit tests, using VMs, etc. so that the worst outcome is that they waste time. Which isn't necessary if they devote some attention to properly learning the language.
I thought HN is a place where people don't take everything so seriously (or maybe I should provide some emoticons not to be taken so seriously?). And I also don't understand why people always try to lump together such comments into troll/hater/(in this case)Python-enthusiast category (ever heard of sarcasm?).
I won't explain myself, smoyer's example (except the 'hate' part) pretty much sums up what I think about Perl. And yes, I believe it's a great language, although looking from a state of development of modern languages point of view, objectively speaking, it's a bit outdated language. And therefore, in my opinion, will find less and less applications in the future (and yes, Python is and will be its main competitor in many fields).
When I write in another language I spend a long time looking for a library like the ten I'd find in CPAN, sometimes I find one but often enough not, then a long time complaining about how if I used perl I'd have access to the perfect CPAN module and therefore already be done with the whole project, then basically reimplement the CPAN module in the smaller inferior language, then finally write glue logic to link stuff together.
I never fail to be amazed when I see pages and pages of an inadequate homemade xml parser written in an inferior language or maybe a blizzard of regex, and then hearing bragging about how in Perl the elegant alternative language code would closely resemble line noise. No, in Perl, those pages and pages of buggy code would instead closely resemble one line: "use XML::Simple;" Repeat a zillion times over.
My "perl" programs / systems actually shrink in length over time rather than expanding, which is unusual in smaller languages.