perlmonks.org —"There seems to be a lot of posts recently along the lines of "Perl needs The Solution" and "Perl is Dying" in which some folks appear to be losing the Faith."
Submitted:
1 year 295 days ago, made popular 1 year 294 days ago
Perl Dying? It is just that other languages are getting more attention. The growth of these OO-based, script-like languages (Perl, Python, Ruby, etc.) is fantastic; however, not all of them will make it to the finish line. Instead, I expect to see 1-2 of them finally capture enough of the see-sawing mindset to take the crown.
By then the next languages ready to replace them should be coming online in new small communities. The cycle will begin again.
Real hackers will switch to LISP once they realize they can easily do whatever they want. Other languages get in the way of solving the hard problems, LISP provides tools to solve the hard problems quickly so you can move on to do other things (like becoming wealthy).
Faith? Perl isn't a religion. It's a programing language. Faith is for fanboys and their fanboy johnny-come-lately languages.
Perl isn't being shoved down anyone's neck like these fanboy languages because there aren't a bunch of shiny new books on the end cap of your local mega bookstore to sell.
The rest of us have work to do and don't feel the need to evangelize,
I use perl everyday for converting our old data reporting systems into a format that can be imported into a database. I think that Perl is one of the best forms of "glue" to make disparate systems work together.
As a "Practical Extraction and Report Language" it does a great job when it comes to doing alot of text dirty work.
I use Perl on a daily basis simply because it's the best tool for most jobs.
The reason it's the best tool is because of CPAN. So many modules, ready to use, to do whatever you can imagine. I know a lot of the newer languages are making headway to catch up, and that's good. Variety and choice is best. But I'll meet them when they get here.
I don't think Perl is dying any more than duct tape is dying. It's the oldest (and largest) in a category of dynamic languages, and the category as a whole is showing incredible signs of life. Today at OSCON Tim O'Reilly will present part 2 of his market trend analysis, where he will break down the trends based on book sales by programming language. ( Part 1 - the overall trend - is here: http://radar.oreilly.com/archives/2006/07/state_of_the_computer_book_mar_1.html ). Later today the analysis should hit his blog. It is always interesting to see.
My prediction: Ruby, Python up (Ruby WAY up). Perl, PHP flat. C, Java, .NET down.
I've said this before, and I'll say it again: Ruby is everything you need in Perl. Perl 6, that is. Right now.
Sure, Perl is a great language, but Ruby is the future, except it's already happening.
As long as Perl makes programming easier it will live. It's hard to imagine that the vast resource of modules at CPAN.org will be reproduced let alone surpassed by another language any time soon.
A cheap and handy Windows compiler is also available: http://activestate.com/Products/Perl_Dev_Kit/
Perl is dying. Don't get me wrong, I love Perl. My entire blog is a custom Perl hack job using PostgreSQL on the backend. But Perl is falling quickly out of favor. The reasons are myriad, but among them are its sometimes Byzantine syntax, the plethora of more mainatinable languages that do much of the same work,and the lack of any true improvements to Perl for a loooong time. I'll continue to use it because I'm getting out of IT and have no desire to learn a new language, but Perl's days are numbered. So are C's. Oh, we'll always have Perl code. And C code. And we'll need people to maintain it. But the number of job openings in engineering in these languages is dropping off. Your hard core fast code is still going to be C, especially in the Unix environment, but there's a reason why universities aren't emphasizing six semesters of C like they used to.
If there was a resource where I could find answers to questions like 'Where is my CGI.pm' in Java' (for example) more people would try switching to other languages from perl.
Getting started in java/tomcat/struts/eclipse (for example) to a minimal level for a guy that is a perlmonk. Sucks, more time is spent in dicking around with tomcat than in programming for a long initial period and then to find that your @INC effectively is barren.
This coming from someone thath as tried many times to pick up a few new languages in my spare time and attempting to do something like WWW::Mechanize does in java or .net is terrible. Or it requires a significant layout in cash to replace what is CPAN.
Every time I've tried to learn perl (three or more times), I've recoiled in horror and switched back to python.
Perl will not die because it is too entrenched in industry -- there are still too many perl adherents in positions of power.
I wonder if there is a correlation between intractable syntax and the longevity of the language. Look at my data points:
Perl: Programmers glory in its unreadability. Still going strong.
C: The power of assembly language, with the readability of assembly language. Probably the world's most widely used language.
COBOL: The most horrible language ever invented. Still used, billions of lines of code still in operation. This is one that deserves to die but just keeps going.
Perl won't die, it's popularity will just drop. People new to programming would go for Python or Ruby.
I'm not trying to promote Python here, but seriously - as far as maintainability, performace and (eventually) popularity goes - python gets the top marks.
For those who want to argue with me about performace: Python has an external JIT compiler/specializer module (psyco). Ruby's rubyjit is still unstable, and perl has nothing similar at all.
My company just approved replacing all Perl programming with Ruby.. that's not just new development only, they want all existing Perl applications eventually replaced with Ruby.
Not in corporate Ameica. We're using it all over the place in big IT shops. Maybe with "hackers" who flock to the language of the day -- Remember Eiffel? Objective C. They were once going to kill off C++.
Often in this thread, people have said things like 'We'll always have (C/Perl/whatever) code, and we'll need people to maintain it.' I don't understand this. Why do people think this? Any language you can name to make this statement about, as well as the equipment that it runs on, are what, 40 years old or so at most? You seriously expect any of this code or equipment to be in use for any non-trivial application in say, 150 years from now?
What Perl has over other scripting language is that it is feature rich. Very rarely do I ask myself, "can Perl do that?" There is usually a module out there that can do what I need it to do. That being said, php, ruby, and python are cool. They are doing certain things better or are easier to learn or whatever. Sure Perl's learn curve is steep but once you get with it you wonder how you got along without it.
The networked world is waiting and wondering, "Where is Perl6? Does no Perl6 today mean Perl is dieing?" Yes, the release of Perl6 has been delayed for a number of reasons. Not only are they making changes and additions to the Perl language, thank you Damian Conway, but they are trying do things a different way, thank you Parrot, Pugs, and other software here and yet to come, and while maintaining compatibility with Cpan Perl modules. Not an easy trick.
I have a very hard time demanding that “It”, Perl6, get done when I'm not doing any of the work. It has been a long time. To outsiders not having regular releases make people fell that Perl is a stale project. That is simply not the case. Perl5 has regular releases. Also, Perl's technical strengths of extendability by modules have made the need to get to Perl6 less urgent.
The main reason to make Perl6 happen is more political than technical. Perl6 needs to get done to show the rest of the network world that the people engineering Perl6 can complete this project. Also keep in mind that when you think Perl6 you must remember that Perl6 is tied to the release of Parrot.
I use Perl and this is one coders perspective. I'm sure someone else has a more accurate view of things.
Perl is, I understand, a classic write-only language. In fact it may be the language which coined the term. The installed base of perl programs is huge, effectively preventing a meaningful cleanup at the syntax level. So Perl code won't get any cleaner. On the other hand, the benefits of an easily readable langauge (Python,Ruby) are starting to outweight the advantages of wizard-like power that Perl confers. To be sure, the enforced sanity of Python and ruby becomes most useful in pressurized environments, but it is also a useful check at the management level - if you're managing someone writing in Python, there is a very good chance that you'll be able to skim their code at the end of the day and pass the torch when necessary. With Perl, you have to roll the dice. (It has been established elsewhere that maintenance, testing, and debugging is far more costly than initially writing software.)
It is really depressing to see the number of comments that refer to perl being an obtuse langauge (write once read never). I think this unfortunate distortion is a product of a few things:
1. perl hackers themselves delight in the arcane aspects of perl and associate complicated strings of punctuation with programming skill. This is a major turn-off for anyone new to programming or for corporations.
2. perl's strengths at manipulating data make it a good choice for writing one-off scripts to handle a specific problem- these might be truly 'write once' scripts but they are basically the equivalent of mucking around with the shell in *nix- of course these provide good evidence for people looking to justify their claim that perl is confusing.
3. most people who repeat that perl is obtuse have never used it; they have been exposed to the statements written by people who have observed the behaviour in point 1 and justified by examples from point 2.
These newer languages are getting a lot of hype but that doesn't mean that they are replacing perl. perl has a huge user base and once perl 6 is released, the hype will all be focused back on perl. I would prefer that they take their time polishing parrot and perl6 before releasing as the amount of attention that will be focused on perl will be huge.
Perl hasn't had many exciting new features added in recent years (discounting the joys of CPAN) but it already didn't lack for many features (short of the ugliness of its OO).
In the meantime, I suggest learning at least two of these newer scripting languages (e.g. perl, python, ruby), not to cover your bases, but as a way of learning more about programming in general. Remember, the perl mantra of "There is More Than One Way to Do It" doesn't just apply to perl but to program solving in general.
Cobol and FORTRAN77 are still alive, guys. Get a grip on reality. Perl5 is may be as fat (meaning, N of lines of code used worldwide) as those guys are.
I never understood the "perl syntax sucks" arguement. Jesus christ what is the big deal about a $variable, @array, %hash, or a &function. How is that so difficult to understand? To me it makes it *easier* because I dont have to scroll through code looking to see what variables are declared as, I can see it right away, and I dont have to do the hack of writing the type in the name.
How is it that @names is too complicated for any competent person to understand that this is an array named names, but array_names in another language is ok, or pnames, or arrayNames or m_names, or any other hack to do what is automatically in the perl syntax. How about just names. What is this? Is it an int, string, float, array? Is it a pointer? Is it a function? Let me waste time searching through the code to find out.
And for the default variable, why do I have to jump through the same hoops everytime to loop through an array?
for( @array) {print;}
OMG what is this code doing? There shouldnt be default variables! The code is hidden! Well if you use your brain and read the specs of a language this is not hard to understand at all. People who use inheritance to abstract 20 ways around a project in java/python/smalltalk all of a sudden cant figure out what the default ($_) variable in perl does? Come on people this double standard is silly.
Good perl is easy to read, good java/ruby/python is easy to read. Bad perl is difficult to read, bad java/ruby/python is difficult to read. The end.
I don't particularly think it's dying, I just think there are better alternatives.
But there are people who believe in Perl in a religious way. I was told a few years ago that I HAD to use Perl since none of the other programmer's in my department didn't know or could not learn my language of choice.
No biggie, Perl was my first language, and I think it has a lot of utility.
I like strongly typed languages, as it makes it necessary to understand the right datatypes for the dataset.
I can see how a beginner would right really innefficient code using a weakly typed language, but at least it would be legible.
I have seen some poorly written code in my days, but that is really the programmer's fault, not the languages as was already said. Perl just makes it easier, cause it utilizes meta-character operands and delimiters, and allows for multi-function dereferencing.
Perl's OO implementation nowadays is still *****,and I hope v6 fixes that, and it's scope, since it is also kind of asinine.
I love it's hashes though, they are pretty damn fast !
I don't know about mod_perl, but while(1) in cgi Perl does nasty things to servers. And even though I personally never caused a race condition, a lot of the senior programmers in my department did ! It was rather funny to watch them bolt to the server room cause there weren't enough system resources to run SSH anymore. Good times ;)
Maybe it's just the servers that run CGI Perl that are dying, lol.
Hopefully mod_perl has memory management, like other languages do.
Perl has it's stong points: If I wanted to search through an aggregate dataset ( 100,000+ records ), and do pattern matching, and pass that info to another function which would dump it into a formatted XML file, I'd probably only do it once, and only do it on the command line in Perl.
After that I'd put it in a database.
But for anything else, there are better alternatives.
And in the end, it's all about the right tool for the job, really.
Besides, Perl's not going away, it's installed on pretty much every FreeBSD/Linux/Solaris/HP-UX and AIX system by default. ;)