If I didn't grab your attention with my Perl 5 Is Dying post, allow me to follow up.
First, to reiterate my main point: if only Perl programmers know that Perl isn't dead, it's dead.
Or maybe those of a political bent might appreciate the observation that for many people, perception trumps reality. Seriously, perception trumps reality. If decision makes perceive that Perl is dead, we can all laugh quietly at their idiocy. After all, some COBOL programmers are still laughing.
Got that? Really? Seems to me a few people either missed that point or dispute it. Fair enough. Now sit back and relax.
When I was living in Portland working for a company called 'OnSite Technology', we had trouble hiring Perl programmers. We had no trouble finding Perl programmers. They were a dime a dozen. People write a couple of admin scripts in Perl and they put Perl on their CV. Now don't get me wrong, I have Java on my CV, but I would never dream of sitting down for a Java interview without their knowing up front that my knowledge is pre 1.5 and I don't know any of the modern tools. It's only there because I want employers to know that I have some exposure to it, not that I think I know it.
Now, maybe I'm just being naive, but somehow people with Perl on their CV think they can do this job, but they can't. Not even close. At OnSite we struggled so hard to find programmers that we hired one of our programmers from California and another one from Idaho (or was that Iowa? I forget). Two-thirds of our Perl programmers were from out of state because that's what we had to do to keep our company going.
It's not just Portland. In the "dying" thread, mock complained about companies in Victoria and Vancouver having trouble hiring Perl programmers. We're having the same problem here in London. My brother (the Java programmer, not the one banned from Portugal) tells me that he can't find Perl programmers but Java guys are a dime a dozen. Here at the BBC, I've been told that lack of competent Perl programmers has been one of the reasons we've considered moving away from Perl. Many employers I've spoken with in London tell me the same sad story. In fact, it's bad enough that Dave Cross picked up a Simon Cozens' project and offered a free Perl class at the BBC. We might even do this again.
Oddly, I hear that Python has a similar problem (I wouldn't know), but that Ruby and PHP don't. While this is still all anecdotal evidence, when employers tell me that they can find developers for languages which are not Perl, I find that interesting. And maybe they're wrong, but like the whole "Perl 5 Is Dying" meme, it's still a problem.
So, you've got a great product idea and need to start a new team. You've heard that Perl is really quick to develop in, but you hear that Perl is dead and you can't find any Perl programmers. Hmm ...
We can point to Perl's rather flat job trends and claim we're not dying, but others can point out that we're not growing. Of course, other languages have flat job trends, but they're also not fighting the bad PR we are. We can compare relative job growth in our direct competitors and see that we're dead last. I suppose we can wait until the pain really sets in (and I know that some will), but then it will be too late.
Publish articles. Publish articles in places which aren't typically Perl-centric. Blog about Perl. If you have a Perl-related site, try and make it look modern, not like some throwback to the 90s. If you don't have the skill for that (I certainly don't), ask for help. If your bosses say "Perl is dying", politely correct them with information, not faith.
And if your bosses counter with "we can't find good Perl programmers", well, I ain't got no advice for you there. If the decision makers and new programmers decide that Perl is dead, then we know where we're going. It's a vicious cycle we have to break. In the past few years, dynamic languages have been carving their own niche, but Perl's not well-represented there even though many of them learned their hard won lessons from us.
There is simply no way you can compare recruiting Java skilled programmers to recruiting Perl skilled programmers.
Java is hugely mainstream with large numbers of graduates churned out who don't even know how to set classpaths or sort lists.
Perl is not mainstream and has graduates who trained in it at work or at home, it's rarely a first language or formally taught.
Recruiting good staff is hard, the size of the pool doesn't make it any easier.
Recruiting good staff who have specialised a bit (i.e. become good at perl) is a bit harder.
Otherwise you're doing it wrong.
The BBC are struggling to get staff because they are paying well below market rates, they always have, and likely always will - look at the contract rates for the BBC, the only time people start to really look at the beeb is during a recession when the better paid jobs aren't as available.
The fact that a couple of people in north america find it easier to find Java people doesn't reflect on Perl much, it's always been easier to find Java people, it always will - Perl's pool of skilled coders could increase by 500% and still not come close.
When you compare to Python and Ruby, you see that they are only growing fast relative to their very small starting size, the actual numbers don't add up to much, and have already peaked, the growth of less mainstream languages than Perl is now static or seasonal.
Re:Comparing Perl to Java is silly
perigrin on 2008-12-04T17:14:14
You've totally missed the point. It isn't that it is easier to find Java programmers than Perl programmers, it's that it is *hard* to find *competent* Perl programmers for a wage that the employer can afford. While it is true that Java programmers are churned out of University at a dime a dozen, they remain in the language and fill out a continuum of competency. Your response is "Pay More", but that again ignores the underlying problem (and the realities of the real world).
In a healthy community there would be lots of people across the continuum of competency, and many would fit within the price to competency ratio that the BBC is trying to hire. In an unhealthy community (one that isn't dead, but say has some kind of systematic problem) you find pockets of competency you simply can't fill. Either people will be too experienced and have salary requirements that are way beyond your budget, or you churn through dozens of incompetent programmers.
The fact that there are (several cause I've heard it too) stories out there about how hard it is to find competent programmers means that we have these holes in our community, and that the Perl community is sick.
Re:Comparing Perl to Java is silly
TeeJay on 2008-12-04T19:19:13
I think there is actually that continuum, but some employers are in denial about what they actually need.
recruiting is hard, recruiting a senior perl programmer for less than would be paid for a senior programmer in C++ or Java and then complaining is what I've seen.
The BBC contract's I've seen fall within IR35 and you'd better paid in a decent junior role. That's nut's.
At my previous, and current company they've run into the same problem, as well at as another largish dev house in toronto. Salaries are getting large, because finding people that already have the skills is getting challenging to impossible.
The last two hires at my previous employer had little to no perl experience, but were already programmers (ie: had CS degrees of some sort). We then took it upon ourselves to bring them up to speed in perl.
Obviously that won't work for everyone, but if you hire smart people that don't know perl, they can be turned into excellent perl programmers. As an added bonus you don't have to untrain bad perl habits out of them, and if you're working on 'new' platforms (catalyst, moose, badger, whatever), they aren't as likely to want to go back to what they know.
Re:Hiring strategies
Chandon on 2008-12-04T19:42:42
This is really the key point. A good programmer who knows a couple programming languages already should be able to train into a new one in about the same amount of time it's going to take them to get used to your code base anyway.
For Perl, if you can find someone with both PHP and Java experience or experience in Ruby or Python, you've basically won.Re:Hiring strategies
mndrix on 2008-12-04T23:49:47
I run a very small consulting company and that's what I did too. I hired a Python programmer and had him learn Perl. He's very smart and picked it up in no time. Soon after he was hired, I sent him a copy of Perl Best Practices and he learned many good habits from the start.
Re:declining average quality of Perl LOC written
TeeJay on 2008-12-04T16:38:52
confirmation bias much ?
I think those who *do* care about quality have got on with it, that's why we have some seriously good tools for to help code quality, in every area from profiling, to perl critic to unit tests, to smarter refactoring editors : whether using perlisense or other tools inside vi or emacs, or using Padre, Kephra, Komodo or Eclipse.
I care about quality, and Perl has delivered, everything from 2 generations of ORM that beat anything available from other dynamic languages, to CPAN modules with near 100% test coverage and a very high quality of documentation, to a wiki that's grown from 0 to nearly 1000 pages in under a year, then there are all the metrics available allowing me to check the quality of dependancies, and know in advance if a version of a module will install and pass tests on any given platform and version of perl.
All in all, none of the other dynamic languages come halfway close to delivering the kind of quality I expect and have expected of me, and many of the bigger commerical languages can't even match perl in some areas.
so meh!
All evidence contradicts TIOBE and the comments you see on reddit, apart from partisan anecdotes of people who have jumped ship and want to convince themselve and/or others that they are smarter.
Re:declining average quality of Perl LOC written
mkc on 2008-12-04T17:05:21
Re confirmation bias: No, what I see is clear cut. Better to argue instead that my case is not representative. I work in bioinformatics, and the Perl is pretty uniformly awful--mostly written by biologists I suppose. (When I say "awful", I don't mean "unimaginative" or "not what I would have done", I mean "poke your eyes out and run screaming".) Now, it may not be Perl's fault that a large number of people writing it are not competent, but that doesn't change the fact that randomly sampling Perl code, particularly in some application domains, draws very poor code on average. If I loved Perl, I'd be trying to figure out some way to change that situation, because it seems to be something that would repel people from the language.Re:declining average quality of Perl LOC written
chromatic on 2008-12-04T18:36:18
I work in bioinformatics, and the Perl is pretty uniformly awful--mostly written by biologists I suppose.
I suspect that most of what you see is due to the fact that Perl allows non-programmer biologists to get things done without having to be good programmers. No one's devised a system by which you can turn a non-programmer into someone with good code maintenance habits automagically. I'm not sure it's possible.
Re:declining average quality of Perl LOC written
mkc on 2008-12-04T19:02:22
To a degree, perhaps. I think it's more that it gives non-programmers the *illusion* that they are getting things done.
For example, they can write code like "while { print; }" and feel that their code works. Unfortunately, it fails silently on I/O errors, so to my way of thinking it's far worse than useless.
Given that there are alternatives that don't suffer from this problem, this seems like a showstopper to me.
Re:declining average quality of Perl LOC written
chromatic on 2008-12-04T19:10:39
...to my way of thinking it's far worse than useless. Have you ever noticed empty
catchblocks in Java code that trapException e? That's because non-programmers who just want to get something done care more about whipuptitude than handling all exceptional cases perfectly.I consider myself a decent programmer, and I don't check the results of my
closecalls all the time, either. Does that mean that my code only works in my illusion-prone mind?Re:declining average quality of Perl LOC written
mkc on 2008-12-04T22:05:06
Hmm. If I usually don't buckle my kids into their seatbelts, would you say that I'm an inattentive parent (a) most of the time, or (b) only if/when I actually am involved in a wreck and they go the the hospital? I'd say (a).
I don't always check my results, either, but it's usually on my mind because I know it's important, and I generally try to make my stuff reliable before it leaves my hands.
Re:declining average quality of Perl LOC written
chromatic on 2008-12-04T22:37:50
If I usually don't buckle my kids into their seatbelts....
If you have novice programmers writing programs where improper coding can produce death, dismemberment, and other disaster, you have incompetent management. (If that's not what you mean, then your analogy is inappropriate.)
Re:declining average quality of Perl LOC written
TeeJay on 2008-12-04T20:00:23
I've friends who work in bioinformatics, they write Perl, most of it is pretty good, some of them come to Perl Workshops, and the some of the people they work with even give talks at Perl Workshops.
Not all of the people they work with are good, but there is the community and the support there. If the technical people in your organisation are more interested in petty squabling about languages than helping their own people do their job better by hooking them up with the local perl or bio-perl comminity, that doesn't just show how partisan they are, it shows how unprofessional they are.
As much as I like perl, I don't think I could ever be bothered to follow a link from reddit, and join a message board or blog about python, php or even ASP just say how crap it was, and I've dealt with pencil-in-the-eye coding in all of those languages.
The only reason I bother to join in here, is because it's a journal site I use regularly and suddenly a bunch of python zealots appear and start kicking off.
Re:declining average quality of Perl LOC written
btilly on 2008-12-05T01:25:43
As has been noted, bioinformatics has a lot of non-programmers programming in Perl. IIRC, average salaries in bioinformatics is less than what you see in other areas of Perl. The two phenomena are likely related, and both will lead to lower average code quality.
Incidentally the quality of the Perl code that I've personally been seeing over the years has been going up, not down. That's because as my career has advanced I've been working with more experienced groups of competent people. While this is a good thing for me, I'm not sure that it is good in general. Because I also see that the kinds of people who used to write crap Perl CGI programs are now writing crap PHP systems. And sure, most of the PHP being written is bad, but if you get enough people using it widely enough, PHP is eventually going to grow its own circle of competent people.
Re:declining average quality of Perl LOC written
faceplant on 2008-12-04T17:25:02
> Ray Kroc may have been an excellent chef, Ray Kroc sold milk shake mixers.
Re:Incompetent or idiomatic?
TeeJay on 2008-12-05T15:25:44
So I read your post, and apparently it will be unicorns and rainbows, if only sysadmins wrote software beyond their ability in python instead of perl ?
You stated at the start of your blog entry that the problem was sysadmins doing the jobs of programmers, wouldn't it be better to hire programmers who know perl to do the programming and keep the sysadmins to sysadminning ?
Python won't enable them to program an iota better than perl, heck they'll probably try and apply perl, shell and c idioms to python and that would be an even worse trainwreck than what you have now!
I don't understand what people keep complaining about. Perl 5 has some legacy, but it is not broken. You don't have to have a major new release of the language every year to keep it current. Perl is mature, and that's a good thing. It has all you need. It's even fun and exciting; you know it. (At the same time there is the next wave of development happening all time.)
(IMO, saying that Perl is too nice (too easy, too liberal, too flexible or what ever I keep hearing about) is just an absurd subject for criticism!)
So it's all about the applications, the community and marketing. You don't have to have the finest, latest, best and scientifically most interesting language and compilers to make is succeed. Take PHP for an example.
Perl has CPAN and still a lot of very experienced and talented developers - that's an huge asset. The problem is that average evaluator (your boss, your client, new developers you'd like to hire, bloggers and other influencers) do not see/find things happening in CPAN, they do not see the discussions here, they do not find the piles of documentation online and so on. They just google for perl and will be immediately disappointed.
For these people all perl sites look like the development and life on those sites has ended in the 20th century. What would be your executive decision based on that first impression? Just compare ruby-lang.org and perl.org.
Re:make it look better
chromatic on 2008-12-04T23:30:57
You don't have to have a major new release of the language every year to keep it current.
You have to have a sane deprecation policy if you want any hope of avoiding the crushing burden of legacy code. How long did it take to get rid of pseudohashes, for example?
Re:make it look better
pnu on 2008-12-05T07:39:26
You have to have a sane deprecation policy if you want any hope of avoiding the crushing burden of legacy code. How long did it take to get rid of pseudohashes, for example?
Yes, and Perl 6 will be a major milestone in the history of interpreted languages.
However, my feeling is that the Perl community is now lacking entry- and mid-level users in "new" application areas like Web development. I don't see the language details as the problem here.
People are looking for CMS:s, modern MVC frameworks, good looking friendly sites, easy to find documentation, exciting examples and a consistent presence in the web. All can be done with Perl, all has been done with Perl, but people just can't see it. I think www.perl.org is a key issue here. That's a bare minimum!
Every Linux distribution has Perl installed by default, all Apache stuff is there, CPAN is full of recently updated modules. Everything is there, ready to rock! We just have a bad image, crappy web sites and maybe concentrate too much into academic discussion about language features. That discussion and development is important and I see you guys doing wonderful work there, but as a whole, this is not serving the potential new users as much as we should be. It's not your fault, I'm just inviting new and old people to participate into this effort.
Re:make it look better
chromatic on 2008-12-05T08:53:05
I don't see the language details as the problem here.
For the marketing problem, no. That's probably the most important problem to address.
I do strongly believe that language details (and the Perl 5 deprecation policy until now) still matter. Perl 5 has been in a situation where it can't evolve. Hopefully that will change.
Re:make it look better
draegtun on 2008-12-05T16:48:26
re: Perl5 evolving.
I was thinking about this only a few weeks ago especially after seeing some of the excellent things coming out of Devel::Declare.
So wouldn't it be lovely to see things like autobox, Moose, MooseX::Declare, Method::Signature etc become part of standard Perl5.
Methinks we need a clear roadmap for Perl5?
/I3az/ Re:make it look better
perigrin on 2008-12-05T19:40:49
No, I want the stuff currently in Perl core dumped. My thought is that the Pumpkings should be focusing on *Perl* not CGI.pm or Moose or other Dual Life modules.
Someone *else* should pickup the slack and work on dists with this other stuff. The Enlightned Perl organization is already working on doing this for Enterprise oriented Perl, other people to pick it up and run too.
Re:make it look better
draegtun on 2008-12-05T19:49:58
What we (may) want then is different versions of Perl.
Bit like Dave Thomas's suggestion of different versions of Ruby at recent RubyConf... http://use.perl.org/comments.pl?sid=41745&cid=66286
So... PerlLite? Perl++? PerlPlus? Perl5000?
/I3az/ Re:make it look better
draegtun on 2008-12-05T19:52:46
Wrong blinkin link;-( This having to continually login into use.perl.org after every comment is a right PITA!
Correct link....http://rubyconf2008.confreaks.com/keynote.htmlRe:make it look better
perigrin on 2008-12-05T22:30:29
Exactly, I think of it like Linux Dists. There are different dists for different markets, tuners, stability hounds, FOSS nazis, Usablilty wonks
... there should be Perl dists tuned to different goals similarly. Re:make it look better
draegtun on 2008-12-05T23:07:54
Something like this would be very nice....
use dist 'perl5++'; # switches on strict, warnings & mooseX::Declare!
#use autobox; # its there but don't need it right now
class Sum {
has 'x' => ( isa => 'Num', is => 'rw', default => 0 );
method add (Num $y) {
$self->x + $y;
}
}
my $maths= Sum->new( x => 10 );
say $maths->add( 2 );
Re:make it look better
chromatic on 2008-12-06T09:07:39
So wouldn't it be lovely to see things like autobox, Moose, MooseX::Declare, Method::Signature etc become part of standard [Perl 5].
Every one of those distributions is a workaround for a feature that should be in the core language but isn't. There's my evidence for the crushing weight of backwards compatibility.
In fact, it's bad enough that Dave Cross picked up a Simon Cozens' project
Yeah, that's when you know things are getting bad.
we had trouble hiring Perl programmers
And for more than 10 years, I've always had trouble finding a Perl job.
