Use Perl for whatever you want to use it for. Keep in mind that while it is very efficient, some other language may be more efficient at particular types of tasks. That's why Perl isn't written in Perl (but only perl can parse Perl *wink* ).

A well-rounded programmer will have a variety of toolbelts, each filled with a variety of useful tools. A well-rounded programmer will know when it's best to use his carpenter's toolbelt, and when it's better to use his mechanic's toolbelt. Some days he may even need his surgeon's toolbelt. They probably all have utility knives in them. But the MD's hammer has a rubber head, the machineists is ball-peen, and the builder's has a claw at the back side.

Back to the well-rounded programmer. He will know, "This is a job for C", or "Perl will do nicely here." He'll even know when it's very convenient to embed one in another. How does one get to this point? By gaining proficiency in a few prominant languages.

I'm not really one for the "flavor of the day" type languages. I tend to prefer to focus on the ones you see in widespread use. Sure, I may be missing the curved scalple with an eraser at the back end from my toolbelt by not delving into this week's new language. And eventualy a well-rounded programmer will have to get around to gaining some knowledge of a pretty broad base of languages. But stop trying to decide which one is best.

The best one is the one that you feel you can accomplish your task efficiently with. And I mean that with all the insight available to a wise programmer: consideration of not just getting the job done, but of maintainability, portability, and all the other things that may or may not be of concern. Learn Perl. Learn C/C++. Learn Java. Learn a couple others. Only then will you be equipped to decide when to put on which toolbelt. ...Nobody asked which was the best of The Village People. ;)

A well-rounded programmer will have a variety of toolbelts... A well-rounded programmer will know when it's best... Back to the well-rounded programmer.

All this talk of well-rounded programmers makes me want to go on a diet. ;P

ps: Oh? You wanted a serious reply? Yeah, I agree. The Right Tool For The Job and all that.

My three year old daughter loves "Bob The Builder" - a chracter of which the parent of any pre-schooler almost anywhere in the world would know. One of the songs on his album is "Right Tool for the Job". A wonderful thing to remember.

If I want to write a device driver for Windows (something I do as a hardware designer!) then I use C++. Darn, I wish it could be easily done in assembler! When the person paying the bills asks for it I will use VB.

But most of the time my work is not speed critical, is not highly reliant on OLE and generally it is a benefit if it can work on various platforms. Over 30 years of hacking code I have tried oh so many. But my experience tells me one thing.

As an academic in my time I found that the computer scientists never liked Perl - it was not pure enough. Until Damian, and I enjoy reading his material because he has the larrikin Australian attitude to computer science.

As a research scientist and engineer in the 1970's I wish we had Perl. I used to say to my staff in those days that each profession needs two things - its own chain saw and its own duct tape. we cannot concentrate on the beauty or purity or academic rigour of our code unless that is what we are about. When I wanted to solve chained matrices in the 60's I used GE TimeShareBASIC - it was what I had access to, so it was the right tool for the job. In the 70's Fortran was better for the job, besides it handle complex numbers directly. By the 80's we had to solve much bigger matrices so we called upon Pascal and the C to implement our sparse matrix solutions. They were the most powerful chain saws we had available to us.

At every turn their was a "right tool for the job". But now the problems I was empoyed to solved have been solved, hundreds of programmers at HP, Aplac and Ansoft. Nowadays I hack a bit of stuff for web apps and a few other things to keep my three year old in DVD's and toys. So Perl is the right tool for the job.

Funnily enough I still get asked to deal with some obscure mathematical problem, or a model that needs evaluating of verifying. Since I discovered Perl Data Language I have been able to stop wasting huge amounts of money on Matlab and still get the job done. If somebody hasn't described Perl as the Chain Saw and Duct Tape of the 90's and btyond, well, I will do it now!

Every langauge has its place and it proponents, I like looking at arguments, and even friendly discussions about langauges. What we must all do is remember that vast numbers of programmers have no formal training, or if they are anywhere near as old as me they probably don't! Each will choose what suits them. In much the same way we choose poerating systems. Some choose Windows/DOS because that is all they have ever known - how many monks were born into a world that did not have IBM-PC's? Personally I don't believe that Windows per-se is such a huge backwards step. I think the entire PC architecture is possibly the biggest step backwards that was made since the inception of electronic computing, and Windows comes a close second!

Darn it, whilst we are going, lets talk about the design of CPU's. Nowadays we try to do everything with 16/32/64 bit machines. In the late 70's a colleague and I designed a 24 bit processor which was optimised for three dimensional array and matrix arithmetic. Then we expanded this to 48 and then 96 bits in the 80's. It was simple, elegant, and for its job, blindingly fast. The early machines used TTL, then bit-slice CPU's. The last one, built only six years ago uses CPLD's. The earlier ones used software floating point, then Intel floating point co-processors, then the last one did its FP using an array of CPLD based FP engines. But I shelved the entire project when my colleague died three years ago. You see we couldn't find anyone who wanted to write microcode for these things any more. Everybody who came to look at it said, well, do you have a C++ compiler for it? Of course the answer was no, but you are welcome to write one if you want to! But of course to do that you have to write the microcode to support it. A single one of our 48 bit matrix engines could outrun anything short of a super-computer class machine when it came to solving matrices. But it died because it didn't have a Java Virtual Machine.

The point really is that whe processors, langunages and architectures we rage Holy War over today are posibly not the best we have had. They may not be the most elegant. But they are what we have and I firmly believe that it is time we put the hatchets away and got down to improving them instead of trying to put the other guy out of business.

jdtoronto has now had his late Saturday night rant is is going to find a convenient hole to hide in till this all blows over, as it inevitably will :)

"...the technology that gets the job done is just fine... "

That statement is of minimal use due to its overly vague and simplistic nature. The technology that "gets the job done" isn't fine if your competitors get it done in half the time, or it's easier to add features, or it's supported on more platforms, and so on (shall I add the extra 200 pages needed to summarize the major points?).

Some of us need the absolute best and place a great amount of effort into analyzing the "technology" that "gets the job done." These things can all be objectively analyzed, it just takes a very large amount of effort, time, and expertise. The scope of what languages are considered isn't anywhere near complete either, but can be filtered fairly efficiently. Due to the rapid evolution of most programming languages results don't stay current for very long either.

This is why you won't see many good comparisons posted online - they take a lot of effort, a wide area of expertise, become out of date quickly, and there's very, very little positive feedback for these things (read: you'll piss a lot of people off). So why would people bother publicizing such things?

The technology that "gets the job done" isn't fine if your competitors get it done in half the time, or it's easier to add features, or it's supported on more platforms, and so on

Bah! That's just semantics. Of course you have to meaningfully define "job"... If the "job" entails beating your competitors to market, then so be it. If the "job" entails making feature creep easy, then so be it. If the job entails portability, then so be it. And whatever technology gets the "job" done is just fine.

These things can all be objectively analyzed, it just takes a very large amount of effort, time, and expertise.

Bah again! No one is arguing that you should pick the tools you use arbitrarily. But, in the real world, after all that "objective" analysis, it comes down to educated guesswork; and you won't know whether you guessed right until the job is either done or it isn't. In fact, the speed with which a choice is made is often more important than the choice itself. While you are expending all that "effort", taking all that "time", and paying for all that "expertise", your competitor is getting it done in half the time. And by the time you get to market, he's already covered his investment... which was only half yours to begin with. Sure, your product is better (maybe) but no one is using it and your profitable competitor is sinking tons of cash into his marketing campaign to make sure it stays that way.

This is why you won't see many good comparisons posted online - they take a lot of effort, a wide area of expertise, become out of date quickly, and there's very, very little positive feedback for these things (read: you'll piss a lot of people off).

Since when did the risk of pissing someone off become a barrier to web publishing? In fact, there are some good comparisons online. And they do piss people off, which is only an indicator of the real reason there aren't more good comparisons online. That is, people don't need comparisons because they already have their minds made up.¹ For instance, I'm not going to bother wasting a lot of "effort, time, and expertise" the next time I'm faced with choosing between Java and Perl. I'm just going to pick Perl. I'm more comfortable with it and I believe it is the better language whether I'm right or not. On the other hand, I might choose C for a project over Perl because I'm comfortable with it as well and I believe it is better for some things. That choice would be made from experience though; I wouldn't be doing additional research.

Note that I'm not saying research is never necessary. What I am saying is that you can research and analyze your findings for the next ten quarters and you will never get a definitive answer that this language is better than that one. All you'll get is a slightly better educated guess. The good news is that after the project is done, your next guess is likely to be much better than could ever be accounted for by research.

1. Generally they make their minds up in one of two ways. Either they learn through experience or they make a choice based on marketing material. Imagine how the world would be if Perl had the marketing support that Java does...

-sauoq
"My two cents aren't worth a dime.";

I'll just reply to the first part, everything else seems to be along the same lines.

And whatever technology gets the "job" done is just fine.

The problem is only partially defining "the job." The other part is defining "done." It's not a black and white issue. Every minute counts, every lines of code counts, every supported system counts, every microsecond of execution time and bit of memory counts. The statement seems to imply that two languages can be equal for a task - they cannot.

Keep in mind that you and your staff's knowledge of a language is a major factor in the decision. If you already know one language, and don't know the other major alternatives you would have to spend time learning them sufficiently to evaluate them, then learning them to a satisfactory level to complete the project. This all takes a lot of time, sometimes more than the project would take, so your compulsion to use Perl may make perfect sense in the vast majority of cases. Standardizing on one language does have many benefits.

But is soo easy to say more:

The biggest objective of OO is for reusable code, and Perl has this like no one.

If you want a job done, Perl does it for you.

And the best, you are free to use other languages with Perl, "inline" show the line for that.

Soo, with Perl you are free to do what you want, since you can change the language by your own (Filter::Simple rox).

And we still have all the good things of portability, speed, openned source, etc..., things that some languages say that are the only one to have.

And all of this for free. Note that is very important to know other languages, specially C++ and Java. But from Java the only thing that is really important compared to Perl is to get the OO style of it wen you have a big project, but we can see that this is not a thing from Java, this is "Design Patterns".

Soo, when some duscussion about that come I always say: Perl has A, B, C, if you can show me another language that have all of this for free whit a good syntax I will be glad to use it. Chouse the language is like chouse a tool to forge the wood, you just chouse what can do the best and faster job. The worst thing that you can do is to chouse a language because it's popular or because you love it, the objective is not the language it self, is what you have to do.