Finally, because Perl is frequently (but not always, and certainly not by definition) an interpreted language, you can write your programs and test them without an intermediate compilation step, allowing you to experiment and test/debug quickly and easily. This ease of experimentation flattens the learning curve even more.

Perl programs are (usually) neither strictly compiled nor strictly interpreted. They can be compiled to a byte-code form (something of a Perl virtual machine) or to completely different languages, like C or assembly language. You can't tell just by looking at it whether the source is destined for a pure interpreter, a parse-tree interpreter, a byte-code interpreter, or a native-code compiler, so it's hard to give a definitive answer here.

My point in the quotes is that there are several different things that people can mean by interpreted.

What your observation about BEGIN blocks etc has to do with is the traditional kind of interpreted language that runs line by line. And no, Perl is not that kind of interpreted language, nor would I be so silly as to think so. I am well aware that Perl has separated out compiling and running code, and I am generally up on what kinds of things happen at each stage. (As well I am aware and capable of taking advantage of the fact that what is run time for one bit of code is compile time for another.)

The second kind of interpreted that people could mean is that you execute a Perl program by running it through a Perl interpreter. Well you do not have to run Perl that way, but perl is the Perl interpreter (so labelled in both common usage and in the documentation) and most Perl programs are, in fact, executed by running them through perl. So as the FAQ says, Perl is usually (but not by definition) an interpreted language - in development work you do not have a separate compile phase. This fact has significant implications for optimizing Perl, the optimization time is seen as part of Perl's startup and so perl simply cannot afford to aggressively optimize. (Else things like loop unrolling would be as irrelevant to Perl as they are for, say, C with a decent compiler.)

The third kind of interpreted is what I actually was thinking of though, that internally you execute Perl through a byte-code interpreter. Of course in theory you do not have to execute Perl this way, but there is so far no widely available alternative. (Some of the Perl 6 back ends are supposed to change that. But they don't exist yet.) And byte-code interpretation presents a constant overhead.

So no, my paragraph did not strictly depend on whether or not Perl is interpreted. But the fact that Perl is usually executed through an interpreter, and the fact that the interpreter internally does byte-code interpretation, are both relevant to the fact that when you can it is usually best to push as much low-level detail and manipulation as you can down to perl.

Well, yes, but you should have qualified that, as most people will think that "interpreted code" is something like what the shell does, and that Java is compiled, while with your definition Java would be interpreted as well.

-- Abigail

I think most people casually use definition 2, not definition 1, of interpreted these days. In other words they call Perl interpreted and think that means that you execute Perl by running it through an interpreter of some sort.

In other words interpreted like JavaScript, Python and recent versions of TCL. (With version 8 TCL moved to a byte-code compiler.)

As for whether there are people who call Java an interpreted language, well they aren't very hard to find...