Slashdot Mirror
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
if __name__=="__main__",
you'll get your turn, Guido.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
O'Reilly puts animals on the cover of books.
http://shop.oreilly.com/product/9780596004927.do?intcmp=ba-code-books-int-search-perl-ct
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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 libraries. I like Perl's data types and regular expressions, but the pain of interfacing with a C library is greater than the convenience of not having to hack up custom hash functions and not bother with dynamic memory management. At least there's PCRE.
Perl 6 is supposed to address this issue. Seamless interfacing with any C/C++ libraries. If it works, would make a lot of CPAN redundant. Been waiting for Perl 6 for years now.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
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).
Sounds like Perl. Powerful, accessible to a complete beginner, reliable, and practically unmodifiable once written.
Give me Classic Slashdot or give me death!
a camel is horse designed by committee.
Do you even lift?
These aren't the 'roids you're looking for.
The syntax is unreadable, of course. And Perl 6 seems to have been rejected by the market. Still, it's a vast improvement over shell scripts.
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 which can be more easily optimized.
Languages which are simple to learn (c++, for example) are generally not very expressive. You end up wasting tons of time debugging issues of memory allocation, library interface details, and datatype conversion.
Languages which are expressive are a little harder to learn, but any individual line in the expressive language does a lot more. Since you are writing fewer lines, and since the fewer lines do more, you end up making programs more easily and in less time.
Yes, the programs will execute a little slower, but as mentioned, this is not important in the demo stage. Your productivity will be much higher.
And there are lots of places where performance simply doesn't matter. Scripts usually fall into this category.
Perl was written by a linguist, not an engineer. As such, it's harder to learn (it's got tons more keywords and context), but once you get the hang of it it's much more expressive. The following single line:
@Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;
unfolds into several lines of C++, plus a subroutine definition with datatype definitions. The following line:
@Files = ;
can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.
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.
That's why there's Mouse. And if that's still too large for you, there's Moo. And when even that's still to large, there's Mo
And you can select which one has the features you need, without the bits you don't care about ... but they've all got basically the same general API, so you can change it up as needed.
Build it, and they will come^Hplain.
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)
a good example of why perl is awesome
The interfacing Linux and MSSQL, the running for five years, or the looking like Greek?
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
a camel is horse designed by committee.
A committee of hard-core desert survivalists who wanted an animal made of pure awesome.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
There is more than one way to do it.
Perl can pretty much integrate anything with anything. Hardware or Software.
It is the Duct tape of the interwebs.
It is a swiss army chainsaw.
And yes,it can be nearly impossible to decipher what the code is doing, Oh, but the moment of enlightenment you have when you do figure out an obscure but elegant piece of code.
That, my friend, is "Why Perl?".
-Xanthos
Average Intelligence is a Scary Thing
I simply was never able to form a mental model of how to use it correctly.
Perl is a multi-paradigm language. It doesn't bundle or insist on a particular model - you are free to use whatever model you want.
All hope abandon ye who enter here.
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.
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 service, often within minutes of the upload.
search.cpan.org has over 3200 results for module names which contain the word "Test".
how to invest, a novice's guide
In theory, yes. In practice, no, because sometimes a CPAN module will insist on one specific module. And woe betide you if you want to mix modules that use different OO bases.
The mere existence of Moose, Mouse, Moo and Mo that purport to solve the same problem is an indication of a deeper underlying problem.
> The majority's view of Perl seems to be stuck back in the 90s.
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 long time.
My Heart Is A Flower
The Python is still more readable. First, you had to import an extra library (which, ok, python is built upon libraries). But, what the FUCK does "qw" mean? One can guess, and only guess, for the context that it's some sort of means to delineate a list. my @whatthefuck = ....;
considering that on a lot of perl you're going to see:
my $whatthefuck = ...;
and that the @ and $ variables are two different things...
And, you may hear the argument that "those are namespaces". bullshit. they're not namespaces. C++, Java, C# & Python have namespaces. @/$ does not denote a namespace. Especially, given appropriate context, you can use one of the other to change how the variable is treated. That's a cast, not a namespace.
Fact is, Perl is W.O.R.N. language: Write Once Read Never
Lots of comments about being unable to read code authored by someone else (as usual), but who are these "professional perl coders"? I'd say I'm an intermediate perl programmer, and I've had no trouble reading my old code or anyone else's provided it's been written sensibly. Hell I've even been able to decipher some pretty Byzantine code when required.
Perl isn't a language without faults, for example OO is not fun in perl. However, it mystifies me to see perl criticised for readability when the coder is, in no small part, responsible for making something decipherable. I've seen shocking code in several languages, where I work I know there's a particularly hairy example of cold fusion we're still struggling to tame... Diabolical use of in-line HTML, thousands of lines of code without so much as an attempt at basic formatting (no indents) etc, etc. It was written by a genius I'm told, but why they deserve that title when they weren't smart enough to write something we could maintain I'll never know.