Perl Turns 25
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."
I recently became a fan of perl as my goals changed towards things it excels at - sticking together big other functionalities easily.
Why guess when you can know? Measure!
...And is sexier than ever.
If you want news from today, you have to come back tomorrow.
I wrote an app in Perl once. It was the only language that I could get to reliably connect to MSSQL from Linux.
It was fun to write, but I go back and look at the code now and it looks like Greek.
On the upside it's been running for over 5 years and having no problems at all.
Perl where are you tonight
how can I now run scripts on my own
I searched the filesystem
even looked in slash sbin
They rm'd the sym link and pffft you wuz gone
Wansu, th' chinese sailor
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.
Runesabre
Enspira Online
What can perl do that newer languages such as python and ruby can't do, and do more readably/maintainably?
I understand about path dependence and sunk costs, which is why we still have COBOL, I'm asking about language features that are unique to perl.
http://moritz.faui2k3.org/tmp/perl-cake.jpeg
Okay, so let's have a roll call of those of us using Perl 6 in production.
Hands?
Anybody?
Kriston
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).
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.
I often don't like the choices people make, but I like the fact that people make choices. That's why I'm a conservative.
And, in python: list = [1, 1, 2, 2, 3, 3, 4, 4, ] unique = set(list)
Which is more readable?
use List::MoreUtils qw(uniq);
my @words = qw(foo bar baz foo zorg baz);
my @unique_words = uniq @words;
What was that about readability?
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 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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
WHAT?
Ahem. "Languages which are simple to learn (c++, for example)".
Perl has lots more reserved words than c++.
(Examples: "say", "not", "and", "open")
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 operator on first reading.)
Perl has several contexts, 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.
Perl has all the overloading and class syntax found in c++.
Perl doesn't have a precompiler.
Are you using 5.16.2?
Are you using Moose/Mouse/Moo for complex data types and/or object oriented programming.?
Perl is alive and well.
If you think of 5 as being a syntax identifier, then you might be pleased to see all of the development that's gone on since Perl 4 gave way to Perl 5.
It sounds a little bit like you're complaining that Perl's development has not followed your idea of semantic version numbering.
My Heart Is A Flower