Here's an experiment you can do to see the difficulties involved in bringing Perl into the enterprise:
- Write some standards (i.e., use strict, -w, include pod comments, etc)
- Write a simple application (irrelevant as to size/functionality)
- Have someone add new functionality to your script utilizing the same standards
- Have a third programmer review and implement the results
Track all time required to communicate to successfully complete the experiment and multiply times the number of programmers in a large organization.
I don't like having to be negative on this subject, but Perl is what Perl does. If a language doesn't enforce standards you have to rely on the coders... This is like trusting your business to M$.
I do not doubt that there are shops where this is a silly experiment, however out of some 1500 programmer/analysts in the corp I am of only a dozen or so utilize Perl, and I don't think any of us like each others particular style and we all dread touching each others code.
| [reply] |
Are you aware of how little standardization in coding actually exists in J2EE? When I was writing Java code at a recent job, I had to work on some other people's code that was just horrendous. The Sun coding guidelines really just scratch the surface, and most people don't even follow those unless you make them. Things like exception handling, use of recent language additions, choice of libraries, etc. make it fairly difficult for Java programmers to just share code without lots of talking and agreement on standards. Perl certainly allows a much wider range (e.g. beginners can write ugly code with globals and no warnings), but within a group of experienced coders with good style and agreed standards it is no harder to share Perl code than it is to share Java.
| [reply] |
I don't dispute this at all, and am at ground zero of the mess. My point is that with Perl the management hasn't invested in the success of Perl as they have in Java, and this lies at the root of the problem. The wider range of standardization between programmers is the quick way that management can right off giving Perl the opportunity to prove itself.
| [reply] |
By this standard, Perlmonks wouldn't exist if you were correct. People post code here all the time (sometimes hideous), AND get answers and understanding in a relatively short period of time.
The only other reason I can think of for what you are aying is, there aren't enough highly skilled Perl developers.
I somewhat doubt this. There are plenty of examples of large Perl projects out there. In a way you could even say that CPAN is one of them.
Maybe it's just that it's not as industy/money driven as other languages so companies never ask for it. There's no gargantuan company called Pun running around and shelling out the big bucks to convince companies to use Perl in large projects.
As for liking other programmer's code, you are going to tell me that java programmers relish touching each other.s code ;)
Forgive me if I'm doubtful. Maybe it's that java programmers aren't given a choice by the people who buy into the language. Or heaven forbid by the language itself. I would hate to have to write anything serious in java by my lonesome.
If I was in an all java shop, I would have to work on other java programmer's code, like it or not. If I was in a Perl shop, I would have to work on other Perl programmer's code, like it or not. I've also never had the opportunity to work in a company full of Perl programmers. Have you?
How can something be proven to everyone if most will not even try it? I believe there is a proper way to do it with Perl. Maybe there are people out there who have mastered it, and we're just not asking the right questions. I have a feeling it goes a little beyond telling them to "use strict;".
smiles
| [reply] |
