When it comes to machine performance, comparisons that I've seen suggest that Perl has similar performance to Java. C++ is significantly faster.

Of course when it comes to productivity, Perl is faster than Java is faster than C++.

Optimize for the kind of performance that you need.

Of course when it comes to productivity, Perl is faster than Java is faster than C++.

That entirely depends on your programmers. A lot of people absolutely hate to program in Perl. And they'll love Java or C++. They will be a lot more productive in Java or in C++. Lots of others absolutely love Perl, but they just don't get it. Perl gives that too much rope to hang themselves. Sure, they may "finish" a program quicker than their coworker doing it in Java. But their programs take longer to debug, and get send back from qa more often than the Java programs.

The implicit condition is "among programmers of similar aptitude for the respective languages." Comparing apples to apples.

It's hardly a revelation that inept programmers in virtually any language will be outperformed by highly skilled programmers in virtually any language.

---

Caution: Contents may have been coded under pressure.

Familiarity does play a role, but Perl has a very low LOC:FP (lines of code per function point) ratio. There's a table here which compares several languages (it's toward the bottom of the page). Function points are a well-defined measure of how much work a program does, so the LOC:FP ratio more or less compares the sizes of programs that do the same thing in different languages.

In the referenced table, assembly has a LOC:FP ratio of 575. C runs 225. Fortran runs 210. C++ and Java run about 80. Perl weighs in at 50.

The ratio matters because research has shown that the cost of a single line of code remains more or less constant regardless of what language you use. Languages that do the most with the fewest lines of code tend to be more economical over the long run.

No matter how familiar someone is with C++, they still have to write a certain amount of memory management code. Java has garbage collection, but you have to write the boilerplate and conversion code associated with its strict type system. Those trim back some of the advantages gained from familiarity.

The ratio is just an average, though. And for the relatively small difference between Java/C++ and Perl, there are plenty of other factors which can tip the balance either way.

Of course when it comes to productivity, Perl is faster than Java is faster than C++.
This is true if you are editing code in emacs or vi or the like. But if you have a awesome editor such as Eclipse when you are writing Java, Java becomes much, much easier and faster to code than perl. The editor looks up functions for you (and there documentation), compiles on the fly and tells you where errors are instantly. It saves tons of time.

But if you have a awesome editor such as Eclipse when you are writing Java, Java becomes much, much easier and faster to code than perl. The editor looks up functions for you (and there documentation), compiles on the fly and tells you where errors are instantly. It saves tons of time.

And yet I still find myself being more productive with Lisp/Perl/Ruby and similar languages than I am with Java and IDEs like Eclipse or IntelliJ. Frankly the only thing I miss about Eclipse in the Perl world is decent refactoring support - which is a hard problem with Perl I freely admit.

There are applications where the overhead of compilation on the fly (as opposed to straight interpretation - Perl is not an interpreted language) is unacceptable. For those, you really need a language with low-level constructs that can be compiled to highly optimized, targeted native machine code. That is to say, C or maybe C++. Other languages like Java, C#, VB etc. don't cut it, because you have the overhead of a virtual machine to worry about.

What I'm saying is that although you may see, in some situations, a Java program perform better than a similar Perl program, it's probably not because the Java program is precompiled and stored in bytecode form (this is possible in Perl too, btw, but the feature is considered experimental). I would say that short-running programs might be an exception, but even that exception is limited by two factors: 1) until recently Java VMs had such poor startup time that the advantage of not having to compile source code was largely lost, and 2) in both Perl and Java you can create frameworks like mod_perl that allow a piece of code to be run repeatedly in what appear to be separate instances of the program but aren't really.

Now, if you were talking about an actual interpreted language like shell, awk, etc., that would be different. There the overhead of the interpreter slows down the program considerably, because it literally has to analyze each chunk of code before executing it.

1. ++ ease of writing (ie, testing, revising, testing!)
2. ease of revision
3. perl DWIMs

1. compilation at run time can (but, does NOT NECESSARILY) impose an unacceptable cost
2. distribution: all users must have access to perl binary (or you must use one of the "compilers")
3. sometimes what you thought you wanted (and what you coded) wasn't what you really meant

Looking at those benchmarks, I want to point something out - Perl and Java are nearly comparable.

• If CPU alone is looked at, Java is slightly ahead (14.44 vs. 11.21).
• RAM - Perl is slightly ahead (12.48 vs. 9.23).
• LOC, Perl smacks Java around (31.09 vs. 21.10).
• CPU + RAM - Equal (Perl 23.68 vs. Java 23.67).
• All 3? Perl (54.77 vs. 44.77). (Without using golfing techniques, mind you!)

I don't spend ages writing and rewriting while I'm still locking down the basic methodology.

I don't waste any time writing and writing if I haven't locked down the basic methodology yet.

Design first, write later.

Once I went to a conference with ambs, where we saw a guy presenting a complex system built out of two parts.

The first part could easily be done with a tool we had already created, so we didn't bother with it (it was just a matter of configuration). As for the second part...

I can't remember whether it had took 4 guys 7 months or 7 guys 4 months, but on either case it is a lot.

The whole system had been designed in C++, there were hundreds of lines and, of course, it took a while to run.

Our idea: we would try to do the same thing in Perl, come up with a nice solution and show it to the man...

We tried it...

Two of us...

Took us twenty minutes...

All our code could fit the screen...

It was faster than the other guys'...

We didn't show it to him; we didn't have the courage...

Moral of the story: Sometimes, by using a high-level language, you can see things more clearly and brush up your algorithms; that's what we did.

Well, the original question demonstrated some ignorance by drawing a false distinction. If said co-worker included Java in the "compilable" corner, they were demonstrating prejudice and bias (quite possibly driven by ignorance). It almost smells like a deliberately loaded question.

Why would I choose Perl over Java? Less Bondage and Discipline (as opposed to disciplined programming). More flexibility in how I organize and write my code. Greater productivity on my part.

Why might I choose Java over Perl? Maybe I'm taking a course on Java programming where turning in assignments in Perl just won't work...or the use of Java is a requirement. Or maybe I just want to try doing it in Java for the professional development.

Unless you are making a production system, application, or library that will be run many, many times, programmer productivity is probably more important than code efficiency.

The fact that it will run many times doesn't mean efficiency is the biggest of concerns.

I've seen a guy who did that kind of systems saying that efficiency didn't matter for him; what mattered was that things worked.

If your system running is going to slow down others, or delay something, *then* you have to worry about efficiency.

That, of course, for certain values of efficiency :-)

YMMV, of course :-)

And then, of course, we have to look at what kind of efficiency... cpu cycles, latency, memory usage, etc. You're absolutely correct in that raw cpu cycles are rarely the best optimization. In fact, on a multiuser system, a background task run through cron is often better implemented in samll chunks, i.e. shell script or Perl w/ system calls, just so the scheduler gets more chances to take back control to give to another user process. Woefully "inefficient" but far better for the health of the system.

Unless you are making a production system, application, or library that will be run many, many times, programmer productivity is probably more important than code efficiency.

It depends on the situation. Sometimes, timely response is far, far more important than programmer productivity, even if the program is run only once. Deployment of a satellite, for instance. Or a demo for a new customer.

And another one is the community.

You don't get that with other languages :-)

Oh, and the fun! The fun! :-D Of course, you probably don't want to use that argument :-\