On Mon, 2005-02-28 at 12:46 -0500, Adam Turoff wrote: > Stating that the _one_ "worst case for certification" is for Perl > programmers get their managers to pay fees is missing the point. You do > not entertain the possibility that certification could possibly be bad > and do damage to the community, for example.
How, other than your next point? > Another "worst case for certification" is that the community bifurcates > from those who are rabidly anti-certification, and they take their > efforts and talents elsewhere. And their patches. And stop maintaining > their modules. Really? Your suggesting that if a group of people decided to start an indipendant Perl Certification program, and received the support of some others in the community, there are those who are SO opposed to certification that they would just up and swear off Perl completely at the very notion that someone is offering certification? Here I was expecting that there would just be a few people whose dislike of certification was such they vilified those who were involved with offering the certification, while otherwise ignoring them. It takes all types I suppose. But then, when Brainbench started "certifying" Perl programming, why didn't those people leave? > Another "worst case for certification" is the gradual dumbing down of > the caliber of Perl programmers that Joe Average Manager can hire. I > could go on. Shoot yourself in the foot elitism. And wrong functionally as well IMHO. First, I've seen many "Perl programmers" in companies that I wouldn't consider programmers at all, never mind good at Perl. Hell I've been interviewed by people who barely know Perl at all and are the local expert. And by comparison to my own moderate benchmark that's quite awful! Certification doesn't dumb down anyone. Like any other language, if the demand is greater than the supply, some unclueful manager is going to end up hiring the slops. If the certification program was halfway decent I assure you hiring certified Perl programmers would _increase_ the bottom level of people passing themselves of as Perl programmers. Particularly, I think, if the certifications were topical (Web, IPC, etc.) as someone suggested. But please, go on! > I'm talking about ghosts because I'm tired of reopening Pandora's box, > thankyouverymuch. :-) But since you've asked for it, here are some of > the more popular ones: > > - Certification doesn't _prove_ anything. It's mostly a means to > weed out resumes when you have 1000 applicants for one job. I don't think anyone is disagreeing with that really. > - The point behind certification efforts is generally to "grow the > pool of Perl programmers". The logic is that a rising tide lifts > all ships: more jobs for entry level programmers, more jobs for > gurus, and so on. However: Perhaps generally, but the point that has been raised here is not growing the pool. Rather it's providing some lowest common denominator a PHB can cover his ass with. > - there is no demonstrable evidence that there is a mass of > programmers ready to use Perl, if only there were a > certification they could get See above response. > - there is no demonstrable evidence that there is a pool of > employers that do not use Perl simply because there are no > certified applicants Agreed. They don't use Perl because they think Perl is a toy that can't be used for dependable, production quality work. They don't use Perl because they don't think it's maintainable, no matter how good the programmers are. _My_ interest is finding ways to dismiss those myth's and worries, to provide tools for tech/project managers to use to help them convince their local PHB that Perl should be in the running for their project. > - there is no demonstrable evidence that simply offering > "certification" will answer the questions hiring managers will > ask I'll take your word on that. I'm not surprised no one has really studied that. > - Many Perl trainers are vehemently anti-certification. A > certification without a supporting training curriculum is dead in > the water. Of course. So those trainers who are vehemently anti-certification wont have anything to do with it. Those that don't feel so strongly might. Maybe it will create training jobs for some out-of-work Perl Guru's, or encourage some of use to improve our skills to fill that void. I suspect if their was sufficient interest in the certification program that people wanted to pay to be taught, more trainers would appear if needed. > - Sure, they could turn around, and sure, other trainers are just > as vehemently pro-certification. But this difference of opinion > should be resolved before any certification effort moves > forward, and it's been a complete logjam for years. Because it can't be resolved perfectly. Since when has the entire community agreed 100% on anything? It hurts my head when three or four top Perl programmers argue some technical point to no resolution - I end up having to make up my own bloody lazy mind! The best we could probably hope for is to formulate the testing thoughtfully enough that those that are opposed might be able to say it doesn't completely suck. > - Lots of programmers have a whole litany of excuses as to why they > avoid using Perl. Ugly code is one. Excessive use of punctuation > is another. Impenetrable regular expressions a third. "Odd" OOP > practices a fourth. And so on. Lack of certification options is > almost never a reason for programmers to not use Perl. Again, this discussion is not about programmers specifically. Most programmers have their favorite language or three. Frequently holding one as clearly the best quite zealously (and the other being near braindead for their lack of ...). [shrug] Hell, I've heard there are people who swear by Python even, WTF!?! ;-} > - Another reason why Perl is a minority language is that it's not > used in academic curricula. I agree. I'd love to hear suggestions how to work on that. We teach some Perl at BU, both under the bioinformatics program and in some short tutorials, and I'm hoping to expand on that. I seem to recall Harvard having some courses. > Certification will not solve that > problem, either. We'll still have a glut of VB, Java and C# > programmers after a certification is done. > - One reason why many shops avoid Perl is the lack of vendor > support. Certification does nothing to address this. Nope. But who is supporting PHP? > - Even with a certification program, the underlying problems with > Perl still need to be addressed: mod_perl is too hard to manage in > many situations, applications like RT take entirely too much work > to install, and so on. [1] AH!!! > > The problem I was trying to solve was how do you > > get wider acceptance of perl? > > You can try to solve that problem with certification. I wish you loads > of luck, though. I don't think certification will solve that problem. It may help in some cases. What other ideas are worth considering? > The last time Perl had an upsurge in popularity, it > was because Perl solved a new class of problem better than anything > else. Might I suggest that the best way to increase adoption is to > learn from our past successes instead of admiring the green fields in > Redmond or Santa Clara? ewwwww. What can we learn from our past successes that will help future success? What new problems are there that Perl might be able to be a better solution for? You mention making mod_perl easier to manage (maybe we should aim down the road a bit though at mod_parrot?) - what other areas might increase Perl's usefulness? Thanks! -- Sean Quinlan <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
