Related link: http://www.perl.com/pub/a/2004/01/09/survey.html
Adam Turoff lays out his perspective on the State of Perl. I agree with what he says, but I do not like that he has to say it. With anything less than total market dominance, people apparently think that a language is dead (just not Perl), and somebody needs to declare a winner.
Adam divides his space between the Skunk Works of Perl, the Perl 6 and Parrot projects, and “wild” Perl activity, which some people assert is fading into irrelevance as other languages (Java, .Net, C#, Python, Ruby) “eat Perl’s lunch”. As a glue language, Perl can work with almost anything else, letting niche languages step in to do some heavy lifting when necessary. Other languages do not have to lose to make Perl useful—other languages need to thrive. Indeed, Perl is good because it takes the best parts of other languages and combines them into one. Without other languages, there would be no Perl, which started as a way to tie things together, not drive them apart. Diversity increases utility and productivity, and drives evolution. New languages represent new ways of thinking, and we should not be afraid of them.
Perl 5 is what it is, and is just as useful as it always has been, just like Java, Python, COBOL, FORTRAN, and PL/1 are just as useful as they always were. The problems may get trickier, but that does not mean that those languages lose any functionality or stop working. Indeed, those languages are all still in use somewhere. They keep doing the tasks that they have always been able to do. Shortly after the announcement of the Perl 6 effort, Mark-Jason Dominus and I gave an interview to Dale Dougherty, and I said that Perl survives because it can go almost anywhere and adapt to almost anything.
Any language’s right to survive only depends on its ultimate utility. If Perl meets the needs of its users, we do not have to worry about its vitality, and we will not need to discuss how to market, sell, or promote it. Instead of worrying about new versions, we just have to make Perl useful, and most of that work is already done.
I hope so...
It's about the only marketable IT skill I have left (apparently)...
I hope so...
If you can read, write, and learn new things, you will never be short of marketable skills. I would sooner higher a person who can learn and adapt than one who will stay at the same skill level. I can teach someone what I need them to know. :)
Perceptions can matter
I've seen perceptions matter most in cases where a manager at some level must make a decision about which technology/platform/direction to recommend for some unspecified time frame into the future. In these situations, they often rely on trade literature, information off the web, and consulting organizations. If the manager is a good one, they also listen to their people and stir that into the mix.
The reason to care about Perl's "popularity" is that it isn't covered in most of these venues. A consulting organization like Gartner really only talks about .NET and Java, and many managers regard their input very highly.
.NET and Java have their cheerleaders who put large amounts of cash into advertising and promoting these platforms. Since Perl doesn't have a rich company behind it, it's important to have articles like Adam's to refer the managers to. The managers can then make a more informed recommendation without fear of it blowing up in their face.
Bottom line is that managers make decisions based on a lot more than the utility of a language that they probably never use themselves.
Perceptions can matter
I concede that those things are true, but that Perl does not get the attention of Gartner does not mean that it is dead. The world is a lot bigger place than business (remember there is the governmental and scientific communities too---Perl came from an combination of both of those).
If managers haven't seen the many, many articles like Adam's already out there, the yearly installment is not going to help. If we want them to see it, it needs to show up in some place they will look. If open source or Perl is not on their radar, then neither are perl.com or the O'Reilly Network.
I think businesses tend to have their noses too deep in the glossy trade rags with six month old news stories that are post-dated by three months. People doing their research like that are not ready for rational discourse, in my opinion, so arguing the truth is the wrong tactic if that is the goal.
We need to come up with a better way to reach those people.
Perl 6 rewrite
I'm really concerned with the rewrite of Perl in the new Perl 6 project. Currently Perl is hard to learn well enough to be able to read other people's code because of the "more than one way to do it" syntax. Are people really going to want to relearn Perl after spending so much time getting comfortable with Perl 5? Maybe I'm mistaken about how much different Perl 6 will be. I understand that there will be a way to support the older Perl 5 code for quite a while, but what about the amount of time needed to upgrade your Perl skill set? Could this drive programmers to use other languages that don't have the black cloud of a rewrite in the near future?
I hope so...
I disagree, most organizations would not and cannot. I have a friend (who is an O'Reilly author) who is the best programmer I know, period, any language - as far as I can tell companies cannot tell the difference between him (or me) someone who has memorized alot of Java (or perl) syntax. The process is flawed, broken. HR processes are built not to seek out people who can adapt, solve problem under fire, learn and apply new things - they are geared to collate, list and quiz existing experience with list of buzzwords x, y, and z. You don't have 5 yrs of x and 3 yrs of y? Well, no but I can solve business problems using computers better than people with 5 yrs of x, regardless of which tools are used. HR people and many IT managers have no response to that kind of thing, its just thanks, we need someone with experience in x... The above mentioned person was turned down for a job because he didn't know "struts" . Well, I would rather have this guy who didn't know struts on the team than a pack of people who know struts but not how to solve problems and have nothing but one hammer in their toolkit.
Sorry, I am bitter, I have had to drag too many paper "Java programmers" to too many solutions, Java or otherwise. I have solved more Java programming problems than half of the Java programmers I have worked with, and I don't "know" Java.
Whatever you think of Paul Graham, http://www.paulgraham.com/avg.html I think he is correct - "Programming languages vary in power" and so do programmers. I find invariably those who can best enumerate what list of buzz words they know are the one who hover in the background when the time comes to put out fires or get past roadblocks. Most HR departments could no sooner find competent development team members than they could pick that week's winning lotto numbers.
I have become nearly unemployable in todays job market because I don't do any one "thing" so I don't fit the checklists - this is despite the fact that in many of the positions I have been in, I was "guy of last resort" when they went though everyone and no one could resolve a given problem, I got the call and there was no one for me to hand it off to so I had to find a solution. And I am sure many O'Reilly Network readers have had similar experiences. You can try to put this on your resume, but for HR departments and mangers it just doesn't compute until you to happen to win the lottery and that manager starts to say "Well, lets ask [that guy/gal]" so much that it becomes a mantra, then sometimes a light comes on and they say "We sure are lucky we found so-and-so" - Luck exactly. (HR usually never becomes clued in, since they see all serfs of the same pay grade as the same - equally disposable and replaceable)
Note: The book Software Craftsmanship discusses some of these issues, it would be required reading for everyone on my team. http://www.mcbreen.ab.ca/SoftwareCraftsmanship/
6B32 49D4 71C0 C473 4DBC...
I hope so...
It sounds like you have had some bad experiences, but I and a lot of other people have opposite experiences. The trick is finding the place that best fits you.
Resume writing can be an art, and once you figure out where you want to work, do what you need to do to tailor your resume for that, which might include picking up some new skills or meeting some of the people with whom you want to work. Having an inside ally can be very helpful.
I once applied for a job where I did not have any of the listed qualifications, but I found the right person to call and the first thing I said was "I'm the person you want". I got the interview, and almost had the job, when they decided to hire internally. Sometimes you have to make your own luck.
Tact and diplomacy may also help. :)
Perl 6 rewrite
Perl 6 is mostly going to be Perl 5 with more stuff to help you get work done. If you already know Perl 5, the next version is not going to be that hard for you. Remember, Perl already went through a similar transition from 4 to 5, and it is more popular than ever. Most of the rewrite is the stuff underneath the code---those nether regions that you do not see.
Also remember that Perl is really not as complex as you think, compared to other languages. People write seemingly undecipherable code in every language that exists.
As I said, Perl 5 is still going to be Perl 5, so you are not losing anything. Indeed, Perl 4 was around for a while after Perl 5 came out. Perl 6 will even be easier because it will be compatible with most Perl 5 code, and Perl 5 should be able to run on top of the same interpreter once Ponie is complete.