Slashdot Mirror
Perl's Glory Days Are Behind It, But It Isn't Going Anywhere
snydeq writes "Deep End's Paul Venezia waxes philosophical about Perl stagnancy in IT. 'A massive number of tools and projects still make the most out of the language. But it's hard to see Perl regaining its former glory without a dramatic turnaround in the near term. As more time goes by, Perl will likely continue to decline in popularity and cement its growing status as a somewhat arcane and archaic language, especially as compared to newer, more lithe options. Perhaps that's OK. Perl has been an instrumental part of the innovation and technological advancements of the last two decades, and it's served as a catalyst for a significant number of other languages that have contributed heavily to the programming world in general.'"
So let me get this straight: A programming language that found a niche, became massively popular, and is now widely used... is a failure in your eyes because it's not in a constant state of change?
You're kidding, right? The epitome of a successful programming language is that it has become flexible enough to meet the needs of its users without requiring more than maintenance fixes. This is like saying "grep is useless because nobody's completely redesigned in in the last few months!" Dude, stop drinking the Web 2.0 kool-aid. There are things in the computer world that aren't meant to change every day. I know it's hard to imagine when every pundit is screaming "release early, release often" from every rooftop, but speaking from experience... If you go mangling your programming language every few months like (cough, .NET) some companies do, you're going to find your developers bailing out like rats from a sinking ship.
#fuckbeta #iamslashdot #dicemustdie
The fact is that Python today is taking over where Perl would have dominated in the past. That is applications, front-end scripting and where integration of both would be beneficial. If it weren't for Python, I doubt legacy apps that are being migrated away from Perl would have had that path ahead of them. It's a much muddier road through Ruby (not criticism of the language itself, but things are too... different than Python).
If computers were people, I'd be a misanthrope.
"The fact is that Python today is taking over where Perl would have dominated in the past. "
And the reason for that is that python has equivalent functionality to perl (unless you really need to compose an entire program in 1 line of regexp and a loop), can also be used for quick-n-dirty tasks but is actually readable and structured and while its OO system isn't perfect its a damn site better than the nailed on dogs dinner that is Perls.
...Perl will just as dead as Fortran and COBOL.
My opinion? See above.
Perl is certainly right for sysadmins. First, Perl borrows heavily the ideas/syntax/cues from the standard unix shell scripting. I am talking about writing scripts with bash, awk, sed, grep, find, tr, etc. If you know them, you will fee right at home. Perl glues the ideas of all of these tools together into a more consistent syntax, and runs much faster than the speed most shell scripts could ever achieve.
Another important issue is the community. Perl community is filled with people who do system administration (not that there aren't other users of perl), so there are tons of libraries, which are available to use as easily as starting Perl's CPAN shell and having it install them automatically. The best book to learn Perl is Larry Walls "Programming Perl". A new edition just came out.
Having said this, I want to mention a that it's a good idea to develop a good sense of judgement. For example, I always got annoyed by some fanboyish coworkers who wrote Perl scripts when a simple shell script would suffice. I have seen perl scripts that are filled with calls to external shell commands, cp and rm and so on which I thought was stupid. (Need a shell script? just write a shell script). And I still loving using awk and similar tools for writing most of "one-liners". I always found awk to be a bit better suited for that than perl. On the other hand, know when to start writing Perl script instead of shell script. Shell scripts can get clumsy very fast.
Another advise, you may also want to check out Python. I was a Perl person, and recently looked into Python, and lo an behold, I am very impressed. In my opinion Python sets a new standard in cleanness and readability. Take a look at the free book "Dive into Python" as well as the official Python 3 tutorial online. Both are short and can be covered in just a few study sessions. Still, in sysadmin world Perl may be more useful, but Python is a great all-around general purpose language.
To see what I mean, take a look at this discussion
http://stackoverflow.com/questions/3775413/what-is-the-perl-version-of-a-python-iterator
compare the tidy Python code at the top with the proposed Perl solutions below.
Finally, the most striking tool I have used when working as a sysadmin was CFengine. It's the bomb try it. It's a very high level declarative programming language for managing large sites/infrastructures.
Perl is a historically a combination of bash, awk and sed. And for purposes well suited where people would use the former three tools to implement shell scripts to help administration tasks on a daily basis. However, Perl is not so well suited for other purposes, like small and medium sized web applications. Therefore, it will not gain any more ground in that area, as better tools are available. The first Perl enemy was PHP. While PHP sucks in many ways, it was better designed to write simple dynamic web pages. Today it is used for medium sized web applications, which is clearly a dangerous thing, but still it restricts the growth of Perl in that direction, as younger coders came first in contact with PHP and all the hosters support PHP, but not everyone is supporting Perl. Also things like Joomla or Typo3 are PHP based and many people start coding by extending them.
For custom application or other mostly larger system Java-based or .NET-based technologies are used. Perl has nothing to do in that area. It lost its job there many years ago. InterShop was once coded in Perl, but - well - who cares?
As the Unix command shell is only a limited realm (in number of installations), Perl will never become that widespread again. At least that is my assumption considering today software base and structure, as well as the education in programming languages.
PHP is a nightmare. However, most problems with PHP and Perl-web-applications are the bugs in those applications and not in the language runtime environment.
No. Just no.
I agree 100%. Python sets a new standard in simplicity and readability. I don't think Perl 6 will be an improvement upon Python in this area. Python now absorbs all the new users. It even has a big traction in the CS education now (Perl never quite got there). Suffice to mention that big CS departments like MIT and Berkeley have started using Python in their intro to CS courses instead of Lisp. It's on clear to me why anyone other than Unix sysadmins should use Perl for new projects instead of Python. In fact, Python is probably just as fine as a sysadmin tool.
On the one hand, with Perl, you can't even create and use a multi dimensional array without barely comprehensible hacks.
Unimpressed.
http://perldoc.perl.org/perldsc.html#ARRAYS-OF-ARRAYS
$AoA[0][0] = "Fred";
print $AoA[0][0];
I will give you that iteration syntax over a AoA can look a little weird to the uninitiated.
I pretty much stopped using multidimensional arrays as a complex data structure when I learned OO except for the obvious mathematical applications. Although for hard core math I tend to take advantage of octave. I've used Inline::Octave from cpan but thats kinda weird.
I wouldn't do massive scale text processing in Octave unless I had a really good reason, much as I wouldn't do massive math work in Perl unless I had a really good reason.
The easiest "hack" on AoA is not to use them, if the application is simple enough. If you just need a crude data store just make a simple hash. So instead of [2][3][4] as a 3-dimensional coordinate, just store "2 3 4" as a hash key.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Awk is fine strictly as a filter. E.g. read formatted input, do something, write output. If that's all you need to do, awk is often sufficient. Perl on the other hand as a great connectivity to the operating system calls, data bases, networking, etc.
By separating variables to a namespace new keywords could be introduced anytime. Just try this in a language without sigils. So, it's a cool feature guaranteeing compatibility of nowadays Perl scripts with Perl interpreters in 3012.
I wrote this a while ago, but I find it's useful to post it here:
The precondition that you can write terrible code in any language is a mental diversion. You must design languages for people that believe in intelligent design.
If there is low hanging fruit in your garden of eden, people are going to assume that someone vastly smarter then they are placed it there for plucking.
Not even God himself coming down from on high and face to face telling every member of the human race not to touch it is going to keep it from being abused.
That is the true nature of humanity and by inclusion programmers.
perl: An unorganized, but sprawling garden full of almost every imaginable fruit. Regex is a shiny sinful apple at eye level on every single tree. The only way to navigate the garden is to ask the snakes.
python: An organized garden that has one of each kind of fruit. But it's half way through being dug up and replanted into an even more organized garden.
ruby: A newer garden. Heaps of fertilizer make everything grow incredibly fast, but the trees are getting tangled and there's a problem with weeds.
c#: Someone spent a lot of money crafting this garden correctly. They also planted trees that emit a hypnotic pollen that will murder you if you try to leave the garden.
java: A beautiful garden but only when viewed from space. Every tree has exactly 1 fruit, and getting anywhere takes forever. Recently taken over by someone interested in c#'s hypnotic pollen trees.
c++: An industrial farm complete with tractors and combine harvesters, but no safety equipment. As a bonus 98% of the farm does not contain buried land mines.
c: A plot of land and a barn full of seeds. Get to work.
javascript: There's only 1 tree and it grows upside down, but you can find it resurfacing in all the other gardens. It's also sentient, growing rapidly, and trying to murder you.
A few years ago, I started trying to learn Ruby, but I quickly changed my mind because the project at large kept changing, and I didn't have time to follow it. Perl's stagnation has made it much easier to use as a resource in places where stability is key.
Why is Perl great? Very small foot-print, minimal resources for outstanding performance, and flexibility.
After abandoning Ruby (until they calm down), I started exploring Perl and C/C++ with much better results. In my experience, Perl can be very user-friendly, or it can be cryptic... just like most other languages.
For myself, I learned Perl first, but was still interested in languages, and so continued with Python, PHP, Java, and so on. For a scripting language, I settled with Python, and feel that it is far superior to Perl in just about every way imaginable (and yeah, I'm a fan of the indentation, too, though I can see that if that's not similar to how you formatted your code in the first place, you'd not be likely to appreciate it. Me, I come from a C background where indentation far more formal than the K&R style was required.)
I love Python and use it daily, but there's one area where it lacks: speed. Perl is, by far, one of the fastest languages i've used and a very good choice if you're doing heavy batch processing.
In a nutshell, I still use Perl heavily because I get paid to produce software - mostly embedded realtime telecom s/w but also a lot of tools as well. Pragmatism dictates that I use the tools with which I am proficient and which are universally available. Twenty years ago, I had to use Bourne shell more than I liked because I could only count on the availability of /bin/sh. Now, I have the luxury of being able to expect /bin/perl (version 5 no less). This counts for a lot in an environment where my hundreds of colleagues and I use hundreds of different servers with different operating systems, distributions, versions, and architectures.
Yes, there is a lot to complain about with Perl but at the end of the day, Perl is still an excellent tool for many many problems and won't disappear from industrial applications any time soon.