Perl Turns 25 263
Several readers sent word that the Perl programming language turned 25 today. In his commemorative post at the Perl Foundation's website, mdk wrote,
"So what does the future hold for Perl? Well I don't have a crystal ball but I cannot see the language fading from usage in the next quarter century, the truth of the matter is that even though there are languages that can do some of the things that Perl does, some of them do some things better, others do things Perl wasn't designed for, there is no language that has been designed to do the things that Perl is very good at doing. No language in the current scripting languages seems to have the flexibility, maturity and extensibility of Perl. The main power of Perl has always been its ability to quickly adapt, and be adapted, to suit purposes. ... The greatest challenges we will face for Perl is a shifting end-user base that will become more reliant on devices that are feature focused but crippled in application choice, the rise in mobile devices will continue and Perl will need to evolve to work with that. A better challenge for us to face would be the integration with electronically aware, and connected devices and systems, the apocryphal internet of things, in this Perl could be a powerful tool. I also believe that the more we see a divergence of language uses in the other scripting languages the more they will face issues in their core designs, issues that Perl avoids due to its malleable nature, what some believe is the crippling factor for Perl is likely to be its saving grace as it has the power and flexibility to cope with the shifting goalposts of an increasingly technologically reliant world."
And here is the birthday cake (Score:4, Informative)
Re:Recent convert (Score:2, Informative)
there is, it is called "CPAN+Gems+PyPi+Maven" ... amazing stuff out there if you're agnostic. Rubyists, in particular, seem to write amazing tools. Chef and Vagrant are two of my faves.
However, I still don't recommend you use Node.js.
Re:hmmm (Score:4, Informative)
As a Perl master, I agree with your perspective: Perl is the UNIX philosophy taken past its logical conclusion. It is more logical than shell scripts, more terse than C, greater than both for the everyday tasks that befall a serious computer user (and absolutely essential for a UNIX administrator).
Re:Why perl? (Score:2, Informative)
How much of readability is the fault of the language vs the developer?
When the language's answer to new features is to add a new operator instead of a library/function call, it's the fault of the the language. That Perl now has nearly 300 operators, that is a language smell.
OK, embedding C looks much easier in python, but I've never needed that.
Understatement of a lifetime. I've had to expose C++ apis to Perl, Python, Java & C#. Hands down the worst, by several orders of magnitude, was Perl. XS should be held in front of the world for judgement as the worst abomination and abuse of the C preprocessor known to development kind. That XS is held to be the best means of expose C to Perl is an even greater condemnation. By contrast, Python's C API is clear, well documented, and for the most part, any preprocessor macros involved behave and look like well-defined functions. JNI, I've only used it a little bit, so I won't pass much judgement, but the API was fairly clear and easy to understand. C#, the same way. C# has the added bonus that if you're interfacing with a pure C DLL, you can do it with DLLImport attributes. The gotcha there is just making sure you get the function signatures and marshalling correct.
Re:Recent convert (Score:3, Informative)
RubyGems is very expansive, but the quality of the modules that rubyists write is atrocious. The language is such a poor performer (spend 30% of the time doing GC, oh but don't worry better GC is in the next version, oh wait the next version, nm the next version), and the whole Rails community is built around absurd bloat: nobody seems to care/notice that their gems are poorly implemented for anything other than scraping something together.
Re:Why perl? (Score:3, Informative)
Re:Why perl? (Score:5, Informative)
No one cares about ruby. It's a dying little niche language. It had a good run, but that's all in the past now. To me, ruby never really felt complete. (It didn't even get a step method to its range class until 1.8.7) There was always some absurd limitation you had to work around or some needlessly obscure feature or rule to learn before you can do something obvious in just about every other language (What's up with things like this? 10.times { |i| puts i } madness!)
Python, well, python enjoys some popularity, but I just don't think it's likely to hang-on like perl. Probably because of the whitespace issue and the big 2.x 3.x split. Perl filled a particular niche really well, and was a good fill-in in a few others (remember when it powered your website's counter and guestbook?). Python never really found a home as there isn't any particular area where it really stands out -- or is even arguably a good fit. You'll find a lot of "it can be used for ..." but not a lot of "It's really great for ..."
As for readability, well, I can't say that it's a terribly readable language. I get that everyone is forced to indent their code (apparently, the whole world forgot about pretty printers) but that's not all there is to readability. Neither is readability all there is to maintainability. (You could even argue that the whitespace rules actually hurt readability, as it takes away otherwise helpful cues.)
Let's not forget that you don't have to write illegible perl code. Really, it's not required!
COBOL's staying power was due to much more than "sunk costs". It was, and still remains [infosecisland.com], the best tool for the job. You'll find tons of failed COBOL to Java conversion projects from the late 1990's as a testament to that. It's really hard to beat COBOL on performance and even harder to find a language that's as easy to read and maintain. (Not that there isn't lots of room for improvement. It was designed to be readable, however, and it shows.) In short: It's easy to learn, easy to read and maintain, and lightning fast.
Anyhow, to answer your question: Manipulating strings is a strength that is not shared by many other languages to any significant degree, and this makes it a great fit for a broad range of applications to which python and ruby just aren't as well suited. (Working with strings in python 2.x is terrible -- even just outputting them can be troublesome due to the bizarre default behavior of 'print'. This has improved, but not much, in 3.x) I would argue that PHP is popular due in no small part to that as well (I've always thought of it as a simpler version of perl. A related note: PHP was originally written in perl.)
Re:Why perl? (Score:4, Informative)
Couldn't it? Would it be possible, at least in theory, to compile CPAN modules to a binary format that could be linked to other programming languages? Is there any reason that CPAN couldn't be turned into something more like a shared library?
Yes, this is part of the perl6 effort. There are ports of all the other scripting languages to the ParrotVM being written for perl6. Once that's worked out you can write a module in Ruby, run it from Python - it doesn't matter. Use the best tool for the job (which is often the one you're most comfortable with).