All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)
Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
Why my brother chooses Java
One of my brothers (I have four, two dead, two living, and I never knew about 'em growing up) is a project manager in London and he oversees a bunch of Java programmers in a grid computing project. Curiously, while he's not overly fond of Java, he told me quite bluntly that he won't approve Perl in his shop.
The problem is that he knows he could get a crack Perl programmer to come in and do wonderful things, get it done faster than Java and then leave. That's where he's stuck. He claims that finding competent Perl programmers is a tough thing to do. With Java, he feels he can pull just about anyone off the street and even if they're only average ability, he can contain the problem. Not so with Perl.
There's also the perceived problem that many of the large scale issues he works on don't have Perl software packages to support them. Grid computing, robust ORMs (many of those for Perl have all sorts of subtle issues in large projects with multiple concurrent users), threading issues, and so on.
I think there are several problems here, all of which are valid. Most programmers (any language) are awful and since there are fewer Perl programmers, we wind up with fewer good Perl programmers. Perl's security model, outside of taint checking, has never been well-defined. Further, due to the extraordinary richness of Perl and how easy it is to specialize in a particular "strength" of Perl, a good programmer in one area can be dangerously incompetent in another. This can make it very tough to evaluate a potential candidate.
Regardless of whether or not you agree with this perception, it's the perception that many folks share. If the perception is right, we're shooting ourselves in the foot by not working on the underlying issues. If the perception is wrong, we're shooting ourselves in the foot by not correcting the perception. Of course, how to implement those corrections is the tough part. Many don't care (this is the "I have a job, screw you" attitude), so they don't help. Others don't agree on whether or not the perception is correct, so they don't help. Those who agree on the nature of the perception don't agree on the solution, so they don't help. Those who are in full agreement often don't have time, so they don't help.
Meanwhile, another Java programmer just got hired.
Update: I think it's worth pointing out that many of the folks here on use.perl are good enough that I suspect they've forgotten just how phenomenally bad/dangerous incompetent Perl programmers can be. We don't give 'em a rope to hang themselves. We give them a Gatling Gun with a hair trigger and a target rich environment.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Long standing problem (Score:2)
For one-off kinds of projects, he said he'd be hesitant to hire Perl programmers to build something. Part of it is the hiring risk that your brother speaks about, but his perspective was from a risk mitigation perspective. After
Re:Long standing problem (Score:1)
It's not just managers. Far from that. There are many knowledgable people who won't touch Perl with a 10 foot pole. Very good programmers. And they are right, Perl isn't their thing.
It's not just perception. The problems people see with Perl are real. Perl is a handy tool. Multipurpose. But it's also difficult to handle, it's dangerous, and it has a lot of quircks. It's not for everyone. In fact, it's not the right language of many people currently using Perl. If I look at Perlmonks or Usenet, I'd say th
Re:Long standing problem (Score:2)
I'm certainly happy to hear well-known Perl programmers say this. This Pollyanna "Perl for everything" attitude is just as silly as the "Java-only" folks.
Re:Long standing problem (Score:1)
However, I don't think that because I think Perl is the language of choice to solve a problem, anyone else should pick Perl to solve the same problem.
Re:Long standing problem (Score:1)
I noticed that more and more discussions about the future of Perl start. I think, that Perl can get in trouble, because outstanding people have a false perception of Perl.
Why do all people compare Perl and Java? They have
Re:Long standing problem (Score:2)
The problem is that you cannot infer any general rules here. Sure, some people come to Perl from another language, and have learned the fundementals first. Others come to Perl as their first language, with or without an
Re:Long standing problem (Score:1)
My sense of Advertising is not to run to everybody and say "Perl is the Best, you shouldn't use anything else", but to show what Perl is good for. And that Perl programs can be as "clean" and "maintainable" as programs in other programming languages.
Re:Long standing problem (Score:1)
The mistake you are making here is that you assume that it's that problem that makes a language suitable. And while the problem plays some role in picking the right language, the programmer is far more important.
Re:Long standing problem (Score:2)
In fact I don't even mind that there should be another language for this kind of thing, I just wish it could be something other than Java or C#. Something more like Ruby.
Can the "why" be fixed with something other than Java/C#?
Re: (Score:1)
I published an essay on this a few weeks ago: Maintainable Programmers [lesscode.org]
What I learned writing PPI (Score:1)
Java has a simple structure, it's easy to parse. So the editors and toolchain can be made SO much more rich for Java than for Perl.
Then do extra checks at compile time, that we can't do.
They have the equivalent of strict and warnings on by default.
All of these checks are aimed at weeding out evil as early as possible, and managing it when it happens (exceptions).
Of course you can write evil at the level above where the toolchain ca
Re:What I learned writing PPI (Score:1)
Don't forget lackluster abstraction possibilities, a huge standard library, the mad rush to standardize on One Giant API To Do Things, and programming, configuration, and deployment mechanisms that emphasize Lots of Little Fiddly Bits .
The amount of damage you can do has some correlation to the amount of productivity you can achieve.
(There's probably a more profound point related to the idea that there are very few system
Re:What I learned writing PPI (Score:2)
Don't forget lackluster abstraction possibilities, a huge standard library, the mad rush to standardize on One Giant API To Do Things ...
And that's perhaps part of the reason why many seem to prefer Java. Yes, it can shackle programmer creativity, but then, it's harder to hang oneself while wearing shackles. If this analogy is valid, then it suggests that it really is safer for some (not all!) companies to pull the average Java programmer off the street instead of the average Perl programmer.
However
Re:What I learned writing PPI (Score:1)
Certainly not, but any perception program ought to be realistic about features of Perl as compared to other languages.
People criticize Perl for allowing people to write quick one-offs, yet that's an explicit design goal of the language! If people can do that productively, maybe Perl's easy to learn, especially for non-programmers. If Perl's easy to learn, maybe finding decent Perl programmers isn't as hard as it seems -- if y
Re:What I learned writing PPI (Score:2)
Somehow, I doubt that. I don't have any evidence as to why that would be false, but in my experience, that's not as true as it would seem.
Python, too, was designed to be easy to learn. And it seems that any decent programmer who tries to learn Python does. But Perl seems to evoke a viseral sense of distaste in many capable programmers. Python and Ruby, as languages of a similar vintage, do not engender that reacti
Re:What I learned writing PPI (Score:2)
In retrospect, I think I phrased what I said poorly. I hope it didn't sound like I was "bashing" your comments. That wasn't my intent.
For the record, part of the reason I value your input on this subject is because you and I tend to have strong differences of opinion.
Re:What I learned writing PPI (Score:1)
Yeah, but that doesn't say anything. Lines of codes is a non-measurement. It doesn't anything. You might as well argue that NASA is a simple shop as they only have a two vehicles to maintain - much less maintainance than the farm with five wheelbarrows.
A single complex line of code can be much harder to debug (and maintain) than five simple ones.
Re:What I learned writing PPI (Score:2)
The key isn't to live in what Brian Eno would call the "small here" or the "short now". Computing is an evolving story, and what we've seen so far is just the opening chapters.
If you look back 20 years, microcomputers were a stifling platform, because of their anemic
Re:What I learned writing PPI (Score:1)
> of managers who would rather reduce risk at the expense of
> increased power and productivity.
That's a very negative way of looking at the problem.
One thing managers are used working with that we aren't so much is the element of Trust as a malleable entity.
When you work alone, or in small teams, you can learn a lot about people, and trust isn't a big issue.
When you have big teams of people, or work with dozens of outsources, then you sim
Re:What I learned writing PPI (Score:2)
Not at all. It's the engineer's lament that the best solution frequently doesn't win. This is just a case where superior technology (e.g. Perl) is loses out to an inferior technology (e.g. Java).
Trust is a significant part of the social issue here, and it's not something that open source can generally solve on its own. Linux and MySQL are thriving in large part because of the corporate umbrella provided by RedHat (et. al.) and MySQL AB that ma
Perceptions of Perl (Score:1)
Re:Perceptions of Perl (Score:2)
Right now it's merely an attempt to get an idea of how to proceed. There are two types of folks I'm thinking about. Those who can commit to actually doing stuff to help out and those who don't have a lot of free time but are knowledgeable enough that their comments/suggestions are valuable.
I'll probably need to set up a mailing list somewhere to launch this.