Posted
by
Soulskillon Tuesday December 18, 2012 @03:25PM
from the added-support-for-rental-cars dept.

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."

Yup. Me too. It's just awesome to be able to get stuff from CPAN with about the right "chunkiness" and documentation vs say trying to learn some huge monolithic library. Better yet - those cool modules often "accidnetally" document other things, like say, Gnuplot, so you can roll your own specialized versions easier than trying to understand the "native language" dox written by someone who didn't code in some other language, then translated by another non-programmer.
And I can't believe I got first post.

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.

CPAN has some of the highest quality compared to other repos (especially compared to javascript), it has test stats for dependencies, quick access to view the source without downloading, documentation and just about any other info you want. Pypi is great for finding things and installing but supporting information is lacking. Maven I can't comment on but Ruby suffers from the same sort of problems that other brogrammer languages suffering from (more variety in quality and a lack of documentation).

When considering a new project, I look first for libraries I want to use. CPAN has the most commonly used ones, but get a little obscure, and you're out of luck. For instance, CPAN has OpenGL, but not OpenSceneGraph. Then I find out what languages interface with them. It quickly narrows down until maybe one language is left, and most often that language is C/C++. Sometimes no languages are left, and then I have to decide if I want to go through the pain of linking multiple languages, or search for more

There's enough of it working now to start toying around. The "NativeCall" interface got to draft standard status recently, and works, mostly. Lack of many C ("native") data types will be a point of pain for some time to come, though.

Perl 6 has the worst case of second system effect I've ever seen. They said at the outset that Perl 6 was going to be a major rewrite, but I never expected to still be using Perl 5 in 2013. It's a shame too because Perl has some definite rough edges, especially with complex data types and writing object oriented code. The complex data type thing is a big one, most programmers really struggle with how to define a hash of references to arrays or anything like that, and the syntax for accessing or updating

It's a great language actually. Instead of people moaning that people write shit perl (like any other language), why no learn to do it right and enjoy it. CPAN of course is a tremendous resource but even on it's own it's not hard at all to write or understand and on the off chance you see something you don't understand, perldoc will almost certainly cover and well because that's another thing that Perl has (along with Python) that many languages lack and that is exceptional documentation.

Unix is still very dependant on Perl. People can sit there and say no one uses it anymore but they don't realise how many things depend on it. Hell even popular OS X programs use perl which is why Apple's version of Perl can be out of date. In some instances language changes would break the scripts the particular version of OS X.

Come on, it's not that bad if you split everything up appropriately into well named subroutines and such like.

This is one of the most important things anyone approaching perl needs to grok. Perl gives you enough rope to hang yourself, that's why I use it. Lack of awareness of that has bitten me in the backside enough that I've learned this lesson.

What I found in using Perl was that no two Perl programmers could read each others code. Much of the expressiveness and versatility that people talk about comes at the expense of a huge amount of syntax and the ability of the language to assume values (like $_ instead of requiring them to be explicit). What happens in practice is people learn a subset of syntax which is large enough to do what they need to do and it often isn't the same subset that someone else learned. And when reading someone else's code, it can be very difficult to look things up because it often isn't even clear what the syntax is (in part because so much gets assumed).

When the boss hands me a flat text file with 50,000 lines in some random format that needs to be parsed and loaded into the database, I dust off my Perl book and write a short application to read each line and spit out SQL. I don't need the safety of Java or the byte processing of C. I don't need to handle every possible exception that could be thrown when opening a file. I don't need a GUI. I just need to open a file, read a line of text, use some regular expressions, do some tokenizing, and spit out more text into a separate file. Perl is fantastic for that. But I don't find much other use for Perl.

What I found in using Perl was that no two Perl programmers could read each others code.

That's silly. I'm just a medium-grade Perl jockey and I read and understand other projects' code. I find bugs and submit patches.

Perl doesn't force good style on you, but if you follow the guides of Perl Best Practices and check yourslelf with Perl Critic [cpan.org] you're going to produce code that most programmers can follow.

Some people aren't comfortable with 'enough rope to hang yourself', which is fine. Others think that forced indentation is the answer to good code style (I think semantic analysis is better). There are lots of options.

That's partly because it was your first (or one of your few) programs in Perl. You likely made things more complicated than needed for lack of knowledge and experience.I've always said that Perl is a good fit for programmers who can recall dozens of "idioms" (memes), and keep their understanding of its unique semantics fresh. Things like keys %{ {map {$_=>1} @list} } [perlmonks.org] (implementing unique(@list)) and internalizing that every expression is ultimately evaluated as a list. Some are silly, but there's littl

I remember when Perl was the workhouse behind all custom web server development. One of the few times I had "fun" writing code. Such a cryptic looking language that made perfect sense the moments you are writing it and completely alien days later.

That's the case with most object oriented languages these days. OO Perl is the worse. It's not just the language, it's the culture.

Instead of a simple A() calls B() and C() to do work, where B() and C() do real work, I've seen code where B() and C() are almost empty, relying on strange language contructs known only to true believers and their IDEs.

I think you're right on most of that but syntax highlighters. We use them because we like to try to break and improve them, since we know it's almost impossible to get them 100% right, given pragmas and whatnot.

No, there isn't... but there's nothing that encourages it either. And perl has a elatively high congitive load in terms of all the many subtle features and idioms that you need to keep track of. If you're reading code that only uses a subset of idioms and features that you're comfortable with it's fine, but it is relatively easy to end up outside your comfort zone with other people's code unless you are deeply invested in the language. In this way it is much like C++.

Surprisingly, embedding C++ in Perl is easier than embedding C. Of course, that's just my opinion, there aren't a lot of docs on the C++ topic, and I am one of the few Perl programmers who actually enjoy C++.

The Parrot VM http://www.parrot.org/ [parrot.org] is supposed to be for dynamic languages what the CLR and JVM are for Microsoft and Java respectively. If it ever makes it to prime time, then you could use your CPAN module with Ruby, or vice-versa.

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?

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).

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 he

We'll have to agree to disagree there. It may take a while to learn them, especially their precedence, but once you do, leveraging that precedence gives you a lot more power and expressivity than functions.

Which is why Perl6 is making it a one-liner to locally define new operators within a lexical scope.

Having written in perl for the past 20 years, I started out trying to find something that perl can do that ruby can't (ruby is the only comparable language I have in my toolbelt). After a few minutes, I decided that, for the work that I do, the single feature that perl has that ruby doesn't is that I'm very familiar with how to write perl.

I've liked some of the things that I was able to do with Ruby on Rails, and could see how having a MVC framework in perl would be useful, but quite frankly, most of the co

If PERL was a decent language, there would have been no need to develop alternative scripting languages. The fact that one programmer cannot read something written by another when they're both prefoessionals in the same language is pretty damning, only PERL has that claim to fame in over 40 years of languages.

perl is a decent language. The problem isn't the language; it's the programmers. My bet is that it's possible to write unreadable code in any programming language (except maybe COBOL but then you just write enough of it that it bores anyone to death who tries to read it). As an example, take a look at something like what comes out of the Obfuscated C Contest [ioccc.org]. But I don't hear anyone saying we should junk C because it's possible to write C code that is almost completely impossible to understand.

For script-type usages, where I might otherwise have used bash/awk or something, Perl feels like it retains more of the lightweight, quick-to-script aspect. I like autovivification, the implicit $_ variable, etc. They can be used to make unreadable code, but in idiomatic usage they're very nice and not particularly hard to understand.

I don't really use Perl for "big" applications, though. Mostly for text processing and "glue" between other tools.

I used to use perl as my "glue" language, too, until I got into python. Python works just as well in most cases, and usually leaves you with much more readable code. People who haven't used python before can usually figure out what some code is doing just by reading it. With perl? Good luck.

I've used Python for some things, but somehow it just seems clunkier to me. For example, if you want to scan a text-file line-by-line and run some regexes on each line, it's much more explicit in Python: have to explicitly read each line into a variable, hoist some re.compile()s out of the loop if you don't want them being recompiled on each iteration, etc.

Although it depends on what your memory restrictions are, if you know the file you're reading isn't enormous (that is, bigger than the memory you can spare), it's easier to just yank the whole thing into an array off the bat:

lines = open('somefile.txt','r').readlines()# set up your regex and compile it herefor l in lines: # do your re.search or whatever

You only have to compile once if you aren't changing the regular expression from line to line.

Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.

In the demo phase, you're not really worried about performance. The goal is to have something working as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language

Perl has lots more operators than c++
(Example: "//" is an operator in perl. So is "<=>", "+/*", "..", and "eq").
(See if you can understand the flip flop [wordpress.com] operator on first reading.)

Perl has several contexts [perlmonks.org], and the meaning of an operator or function is context dependent.
(Example contexts: "scalar", "list", "null", "string")
(Example differences: Saying "$i = sort @array" has a completely different meaning from "@i = sort @array")

Perl distinguishes a variable from its value.
(Example: $i = 12; followed by $i = "twelve". The same variable, points to one of two values in memory. C++ binds the variable to the memory location, perl does not. Programmers have trouble wrapping their mind around this.)

Perl references are not pointers (but have some similarities). C++ programmers have a hard time with this also.

I've not found python's mechanism for using regexes to be any less powerful than perl's. It is inherently object-oriented, so it works rather differently. I've used both facilities and have never been unable to do what I wanted in either language.

Also note that perl is only faster with regexes if they are static (that is, known at compilation time.) Python does them faster if they aren't known until runtime.

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.)

People are still harping about this? Get over it. Python doesn't care how you do your indentation, as long as you do it in a consistent way. You also aren't wasting lines putting curly braces on everything. And you barely even have to worry about it if you're using any kind of python-supporting code editor for it. I'm not even talking about a full IDE. Even IDLE alone will do the job.

the rise in mobile devices will continue and Perl will need to evolve to work with that

Does this mean Perl is considering to jump on to the tablet bandwagon? I cannot even imagine what that would mean for a programming language. All I do know is that we have lost many a great seamen to the sirens of tabletia. Shipwrecks, shipwrecks everywhere.

Shell scripts are quick and easy, they work and play well with others, but they quickly get unmaintainable after a page or two.

Perl has local variables, real functions, and it also works and plays well with others.

You really can do 90+% of everything you might want to do in Perl. Add in C code if you need something to be very fast, and you're up to 95+%. Well written Perl is no less readable than any other computer language, and more readable

... what does the much-vaunted CPAN contain within it that has unit tests?

Any serious distribution on the CPAN has at least a decent test suite in its t/ directory. Everything uploaded to the CPAN gets run through the CPAN Testers [cpantesters.org] service, often within minutes of the upload.

search.cpan.org has over 3200 results for module names which contain the word "Test".

For the old Bourne shell I agree, but IME bash syntax can be distinctly better than Perl for certain tasks -- typically stuff that's rather heavy on glueing other stuff together.
And bash is becoming universally available, too.

I was going to dust off what little I knew about python to do some trivial selection boxes that would set environment variables, but then I just added "zenity" to bash and it did the job very well in a very short script.

Programs from 1998 still run because the language has been stagnant ever since. Python breaks because it actually improves sometimes. "The main power of Perl has always been its ability to quickly adapt"...seriously? Perl 6 has been stuck in R&D hell for a dozen years now [slashdot.org]. Even the Duke Nukem Forever team is starting to feel awkward about how long it's taking.

Programs from 1998 still run because the language has been stagnant ever since.

You really have don't know anything about Perl, do you? To suggest that Perl has been stagnant from 1998 (v. 5.005) until now (v. 5.16.2) is ridiculuous. The difference is immense. That doesn't mean that backwards compatibility needs to break. You just don't know Perl or its evolution.

Python breaks because it actually improves sometimes. "The main power of Perl has always been its ability to quickly adapt"...seriously? Perl 6 has been stuck in R&D hell for a dozen years now [slashdot.org]. Even the Duke Nukem Forever team is starting to feel awkward about how long it's taking.

Lessee.... Python 3.0 came out 4 years ago. Still, 2.7 is the one installed by default across the board. Some distros (e.g. latest Red Hat) are still stuck on 2.6. Apparently, most people can do without the improvements in Pyt

I like Perl. My company sells software that's primarily written in Perl. It's readable and maintainable because we follow strict coding guidelines, use proper modularization, and have unit tests that make sure our POD documentation is complete and up-to-date.

That said, a few things about Perl worry me. I think Perl 6 is a distraction; someone should take it out and shoot it. I predict it will eventually be abandoned the way PHP 6 was.

Great plans are great, but how about decent Unicode/utf-8 support first??

And by decent I mean a single global flip switch to tell the Perl that the script runs in Unicode/utf-8 only environment, all regexes should be Unicode aware, all file and directory names are Unicode, all text files are Unicode and so on and so forth. Well, you know, a switch to tell Perl interpreter that it runs on a system made in 21st century.

Otherwise, Perl is a great thing. But the bastard Unicode (and locale) support already

And what would be the magic option to make the regexps Unicode-aware? so that e.g. \w would really match all word characters, and \s all possible spaces, and so on and so forth? The `/u` is pretty useless because one has to add it to all regexps in the program - and occasionally it also behaves illogically depending on other options (`use locale` and similar).

The majority generally do not pay attention, and also hate it when their view of the universe is threatened by facts.

Perl will continue to have it's place, as do Fortran, COBOL, etc. It wasn't my first language, and isn't my last, but it's still my bread and butter.Despite using it for 20 years, there are still some things that are idiomatic AWK for me. I'm sure it will be the same way with Perl, even after I've used Ruby or Python for a l

Part of Perl's success early on for CGI, was the fact that Open Source and Free Databases were hard to come by, and/or weren't so useful.The players in the Database Market were charging thousands of dollars for even the smallest usage.To replace the need of the Database we needed a language that was good for Text Parsing. Perl is good at that. However as time went on and tools such as MySQL and PostGreSQL, and Microsoft SQL Server (Not free, but lower cost than the others) started to come up and become mo

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).

Was pretty used with Rexx when had to start messing with perl, almost 20 years ago. Urgh, it was so ugly, at least compared with the (for me at that time) elegant rexx way to i.e. parse strings. But also noticed how powerful perl was, how much more i could do with it, and eventually moved to it as my main scripting language when moved to Linux. Now moving between it, python and bash, depending on the problem, even if i could do most with just one of them. But probably would not be using back Rexx, not sure