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.
Re:Long standing problem
Abigail on 2006-01-26T00:29:07
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 that more than half of the people who program in Perl shouldn't program in Perl. They'd be better off in Java.
If I compare languages with cars, Perl is like a landrover. A very useful car if that's your only car. Drives on the road and all kinds of terrain. You can put a couple of sheep in the back and take them to the vet. Or drive it to church on Sunday. Excellent car, a landrover, despite the lack of comfort and its relative low top speed. But that doesn't mean a landrover is the right car for a cab-company that has a fleet of 100 cabs. That's how I see Perl. Incredible useful language for doing all kinds of small jobs. But for large jobs, where all noses need to point in the same direction for a long time, something else, for instance Java, may be better.
Re:Long standing problem
Ovid on 2006-01-26T01:27:13
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
Abigail on 2006-01-29T00:25:51
Oh, don't get me wrong. I'm certainly in the "Perl for everything" camp. However, I'm not in the "Perl for everyone" camp. I use Perl for everything I can get away with.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
reneeb on 2006-01-26T06:13:12
Why do you think, so many programmers shouldn't program Perl? Many of them started with an other programming language (may be Java) and now start to learn Perl. May be they have to solve a problem that can be solved with Perl in a better way than the solution written in Java would be.
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 different approaches. They should be used for different things. Ok, you can do things in Perl what Java is made for and vice versa, but why should I do that?
I can say, that there is a lack of good Perl programmers. I am searching for Perl related job offers in the internet and post them to http://perl-community.de/ and most of these job offers still appear in the internet after half a year (with updated dates).
Many companies change their mind and search for Java programmers. This can lead to more "problems" for Perl...
Just my 2 centsRe:Long standing problem
ziggy on 2006-01-26T17:07:00
Why do you think, so many programmers shouldn't program Perl? Many of them started with an other programming language (may be Java) and now start to learn Perl. May be they have to solve a problem that can be solved with Perl in a better way than the solution written in Java would be.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 any basic grounding in software, logic, or mathematics.
There are (or at least there were once) very, very many people who advertise themselves as Perl programmers because they understand the syntax (curly brackets, semicolons, sigils, etc.), but not the underlying structure, architecture or execution model of a Perl program of any significant size or complexity. These are the people who probably shouldn't be programming in Perl, and possibly shouldn't seek a career in software development.
So, while it may be possible to code a better solution to a particular problem in Perl compared to Java, the question is really whether a particular programmer can create a better solution, and whether a manager can hire additional programmers to extend that better solution.
This is not a Perl vs. Java issue. It never has been, and we are fooling ourselves when we think it's an advertising, marketing or advocacy problem. The core issue is a social one, and it is very real.
Re:Long standing problem
reneeb on 2006-01-26T23:14:00
But I think, that "advertising" or "marketing" can help to avoid misunderstandings. "Advertising" is not the solution on its own, but it is a part of it.
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
Abigail on 2006-01-29T00:21:23
Why do you think, so many programmers shouldn't program Perl? Many of them started with an other programming language (may be Java) and now start to learn Perl. May be they have to solve a problem that can be solved with Perl in a better way than the solution written in Java would be.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.
Why do all people compare Perl and Java? They have different approaches. They should be used for different things. Ok, you can do things in Perl what Java is made for and vice versa, but why should I do that?Most problems that can be solved well in Perl can be solved well in Java or Ruby or C or some other language.
Perl isn't a language that's suitable for a particular set of problems. Perl is a language that's suitable for a particular set of programmers. Perl has its things that make it Perl. It's terse, it's context sensitive, etc. Rewarding if you can deal with it, but frustrating for many. Some people prefer simplicity, or orthogonality. For them, Perl isn't the right choice. Regardless of the problem.
Re:Long standing problem
Matts on 2006-01-26T17:29:31
The big problem I have with this is the "why" of it. I don't dispute that it's true.
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#?
I published an essay on this a few weeks ago: Maintainable Programmers
Re:What I learned writing PPI
chromatic on 2006-01-26T22:39:50
The situation with Java comes down to one thing. Protection before execution.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 administrators or power users who pick up Java to do a bit of this and a bit of that, unlike Perl, but that may be a point best attached to Abigail's comments about People Who Should Not Be Programmers.)
Re:What I learned writing PPI
Ovid on 2006-01-26T22:55:00
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, that sidesteps a major concern of mine: we can't correct people's perception of Perl by bashing other languages.
Re:What I learned writing PPI
chromatic on 2006-01-26T23:46:39
...we can't correct people's perception of Perl by bashing other languages. 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 you can find a decent programmer, he can learn Perl without too much trouble.
Other people criticize Perl for late binding, value conversions, and dynamism, yet those are also explicit design goals of the language. They allow, in many cases, good programmers to write shorter code than less flexible languages allow. Every line of code you don't have to write is a line of code you don't have to debug or maintain. Perhaps it's possible that you need fewer programmers than you would if you used a less expressive language.
These aren't new arguments, but I haven't seen much advocacy that expresses them in terms of the philosophy and reasoning behind the language. I tried to do that in What is Perl 6? That could backfire, but it's at least a different way to address public perceptions and it might work better than the current, tired approaches.
Re:What I learned writing PPI
ziggy on 2006-01-27T00:37:58
[I]f you can find a decent programmer, he can learn Perl without too much trouble.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 reaction. Perl is respected, but grudgingly so.
If I had to guess why Perl engenders such a pervasive distaste, it's because Perl is multiparadigmic. C++ and Common Lisp are also multiparadigmatic, and grudgingly respected in a similar fashion.
Re:What I learned writing PPI
Ovid on 2006-01-27T00:41:35
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
Abigail on 2006-01-29T00:37:04
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.Every line of code you don't have to write is a line of code you don't have to debug or maintain.A single complex line of code can be much harder to debug (and maintain) than five simple ones.
Perhaps. However, if a Java program takes three times as much lines of codes than a Perl program, but a Java programmer writes bugfree lines of codes at four times the speed of a Perl programmer (it's not just typing speed, it's also the train of thought to come up with the line - and to debug it), the Java program is finished before the Perl program.Perhaps it's possible that you need fewer programmers than you would if you used a less expressive language.Re:What I learned writing PPI
ziggy on 2006-01-26T23:57:23
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 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 resources, and the need to program everything in either BASIC or Assembly. BASIC was good enough for the small little fiddly bits, but anything real required tricksy uses of Assembly. Things only started to take off once Pascal became widely available.
But Pascal was a cruddy language for large scale programming. And soon enough, we had C and C programmers. The good thing about C was that it was close enough to the metal that you could get acceptable performance and build things as complicated as Windows 3.1 that ran quickly enough and almost reliably enough to do something useful with these little boxes.
Yet C is a crappy language for the majority of people writing software. As Joel Spolsky points out, there are entire classes of programmers who can't really deal with pointers, manual memory management, buffer overflows and the like. When it comes down to it, you shouldn't have to worry about pointers or memory management when your task is writing an accounting system or a group calendar.
If you take the long view, all of these languages were just shims to let us get something done while we waited for the hardware and software tools to catch up to where we need to be. If Java has a poor abstraction capabilities, a hugely complex standard library, it's because as an industry this is what we needed for a large class of problems. It also helps to put a nail into the coffin of second systems and gratuitous complexity. Everything that follows Java will need to be a third system (or greater), and benefit from an analysis of where Java went wrong.
Another way to look at it is that Java is solving a problem of managers who would rather reduce risk at the expense of increased power and productivity. Until the tools, education, and computing power improve, we will still need rooms full of programmers doing uninteresting work using tools with blunt edges. Small teams that are skilled enough to run with scissors will still be able to use Perl, Lisp, Haskell, Smalltalk and other such "esoteric" languages to get more done with less.
Re:What I learned writing PPI
Alias on 2006-01-28T09:31:21
> Another way to look at it is that Java is solving a problem
> 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 simply don't have TIME to trust everyone, or sometimes anyone.
You can't instinctively trust the people you are hiring, the people you contract with, your boss, anyone really.
And I suspect that managers get attracted to systems that allow them to deletegate and manage work effectively WITHOUT having to trust them. And the number of entities that are able to trust is finite.
So if you trust Sun + Java, and Sun provides all these protections so you don't HAVE to trust the coders you are hiring 10 at a time, that's totally great!
You might trust Perl the language, but Perl except for tainting Perl doesn't provide many tools that let you not have to trust your coders. Hence the problem in environments where you want to hire lots of coders...Re:What I learned writing PPI
ziggy on 2006-01-29T18:30:20
That's a very negative way of looking at the problem.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 makes it easier for businesses to trust it it. But in general, "better" open source projects like FreeBSD and PostgreSQL fail to thrive in the corporate world partially because of this "lack of trust" (more frequently stated as a "lack of accountability") issue.
However, trust and technology aren't the only two metrics that businesses use to evaluate tools. Staffing and technology maturity are also very big. Risk mitigation is also a big issue. There are others. Accepting that these are all valid metrics used to evaluate tools (as in Perl vs. Java) isn't being negative; it's simply looking at a bigger problem.
Re:Perceptions of Perl
Ovid on 2006-01-27T22:04:20
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.
