It's neither a Programming Language nor a Scripting Language, it's a Glue Language.

...sorry, just having a little fun. Now back to reality: Required reading for any Perl addict is perlintro, where it states the following:

What is Perl?
Perl is a general-purpose programming language originally developed for text manipulation and now used for a wide range of tasks including system administration, web development, network programming, GUI development, and more.

The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). Its major features are that it's easy to use, supports both procedural and object-oriented (OO) programming, has powerful built-in support for text processing, and has one of the world's most impressive collections of third-party modules.

Different definitions of Perl are given in perl, perlfaq1 and no doubt other places. From this we can determine that Perl is different things to different people, but that lots of people think it's at least worth writing about.

perl, and perlfaq1 support this definition and further clarify, calling it "a high level programming language", among other things. I suppose the notion of Perl being a "scripting language" comes from its similarities to awk, sed, and shell script variants. Furthermore, programs written in Perl are frequently referred to as 'scripts', probably in part because the source code is readable by humans (a debatable point) and by the Perl interpreter, "on the fly". In other words, where C is compiled, then linked, and then the source code gets tossed out with the bathwater before product distribution, Perl programs (or scripts) remain in their script-like source format until the final moment before execution. ...and that final moment is pretty much invisible to the user. This rationale for the use of 'scripting language' when describing Perl is my own hypothesis, and I cannot cite a specific passage in scripture.

I have seen interpreters for both C and Pascal. It's probably easier to write an interpreter for those languages than it would be to write a compiler for Perl given Perl's eval that pretty much requires an interpreter or some sort of runtime just in time compilation.

I guess part of the distinction between a scripting and other languages may be the degree of typing and type safety provided by the language with scripting languges generally being less fussy about such things and non-scripting languages being more fussy. At the end of the day "scripting language" is a pretty meaningless label.

---

DWIM is Perl's answer to Gödel

Compilation has nothing in particular to do with a language being a general purpose language in some sense, or a scripting language.

Scripting languages tend to be interpreted and very quick for a certain range of tasks. That is true of Perl - command line Perl one-liners are a common way of automating many tasks.

Scripting languages are often used for batch processing at the command line - that is certinally true of Perl.

Perl makes a lot of the things that you would want in a scripting language easily available, but also provides much more power than classic batch processing oriented scripting languages. Perl is an Uber scripting language.

In my experience, Perl is generally called a scripting language by people who are trying to disparage it and who then flounder a bit when you ask them what the characteristics are that distinguish a "scripting language" from their language of choice.

I like to describe Perl as a Dynamic Programming Language and I'm always careful to refer to my Perl code as programs or applications - never "scripts".

Then why peoples called perl is an scripting language?

Because there isn't any hard-and-fast definition of what a "scripting" language is - so you often find people using it as a shorthand for "languages I don't like".

I think it is a little more complicated than that.

I once worked at a major online retailer where C++ was king and found that many developers sneered at Perl as a 'scripting language'. The essence of the criticism is in line with some of Grandfather's observations in that Perl is perceived as 'quick and dirty' with respect to results but not as a language to use in coding high-performance, scalable and mission-critical software. While I haven't done a lot of benchmarking, it seems believable that for many tasks, a compiled program may out-perform an interpreted 'script'.

I think there is a more subtle criticism of Perl as a language and against Perl developers, which goes something like this:

• Perl allows a developer to 'slap something together' to get quick results for even very complex problems.
• For most real-world problems, quick results are rewarded.
• Over time, Perl developers can become conditioned by the quick-results philosophy and begin to abandon more rigorous software practices, resulting in permanent software that is 'slapped together'.
• When a Perl developer comes up against a serious programming problem which requires extensive algorithm analysis, high performance, high scalability, and high reliability, they can be too impatient to 'do it right the first time' because of the quick-results conditioning.

I know I'm painting with a broad brush, and I suspect this may ruffle some feathers. Although I have resented this criticism from C++ developers, I have to admit that I am often very impatient in addressing problems, and I sometimes neglect to go back and refactor some of the quick-fixes that have become part of my permanent code base.


No good deed goes unpunished. -- (attributed to) Oscar Wilde

I think it is a little more complicated than that.

Well - kinda. The point I was trying to make was, whatever the reason, the term "scripting language" is often used as a derogatory description. It's not a technical term with any sort of hard definition.

One a debate is framed around "scripting" vs "real/compiled" what you often have is really a debate about "bad" vs "good". Which, as you correctly point out, is often more social than technical.

Amusing topic. It's been my observation that scripting languages tend to have "getting things done" their primary focus, rather than performance (C), esthetics (Pascal), safety (Java), etc. Sure, Perl programmers are interested in performance, etc., but normally we just want to get a job done quickly and easily. With the current speed of modern computers, performance isn't required very often. Esthetics are a simple matter of taste, and you'll get in endless debates in most languages on the "one true way" to [align braces|set tabstops|select indentation width|name variables|...]. Safety is important, but not at the cost of being in a straight-jacket.

Perl has many methods of I/O cooked in, with a few simple and extremely flexible data types. So when you want to get a job done, you can simply read the data, stuff it into a combination of hashes and arrays, and get down to it. Other languages I've worked in have all the control you need to create any abstract data structure you want, and a paucity of I/O capability. So when you try to get something done, you find yourself designing a data structure, and then have to figure out just how you're going to get your data into and out of them.

I've been programming in C for nearly 25 years, and when I first saw Perl, I put off learning it for two years because it looks like line noise and gibberish from a "clean syntax" point of view. Then I had to learn it for my job, and I found out how easy it was to get things done in it. Soon after that, I found CPAN and it made Perl even nicer to work with.

Now I'm to the point where whenever I have to do something, Perl is frequently my language of choice. Especially as I'm accumulating chunks of job-related code to make things even easier. I still think in C/C++, and pointers are natural to me. I haven't yet figured out a good mental model of Perl's operators yet, so I'm always referring to the various perl* documents to figure anything out. And I still frequently think perl looks like line noise. 8^) But I keep typing #!/usr/bin/perl -w in the first line of my editor whenever I'm trying to get somethind done fast. (Which, in my job, is all the da** time....)

--roboticus

Forget everything you've been told so far!!

Perl is a war-weary soccer-playing vagrant on the edge.

Or maybe...

Perl is a jaded guerilla vampire hunter with a passion for fast cars.

Oh, I mean...

Perl is a world-famous bohemian master criminal with a winning smile and a way with the ladies

Actually, ...

Perl is a witless crooked gentleman spy possessed of the uncanny powers of an insect.

Yes, idea (and data) shamelessly stolen from "They fight crime" (google for it).

Cheers,
Darren :)

<removes_tongue_from_cheek>

Conversely, a scripting language is a sort of slang for using a type of interpreted language that under unix and linux can select its interpreter program that will actually execute after reading the script into memory, via the special "comment" on the first line, e.g.

#!/usr/bin/perl
[download]

When executing such a Perl script and examining what programs are running in memory before it finishes, (e.g. in unix with the ps command) you will find that the Perl interpreter specified in this magic line is running, not your Perl script or any compiled or linked by-product of it and this demonstrates that it has not been compiled.

Update: BUT Perl becomes a compiler or cross-compiler if it is used to generate object or C-code for eventual loading or linking by another program rather than executing the source at once. So one could argue it is everything it can do: a scripting language, a compiler, an interpreter...

There is no real definition for "scripting language," so you're going to be stuck in your confusion.

People like to classify things, and most people find binary classifications (where there are absolute, unbreachable boundaries between things) more comfortable than continuous ones. Perl is too versatile to be easily classified in this way.

In my world, a script is just like a stage script - Actor A says this and does this, Actor B says that and does that. Except instead of people your actors are programs, typically unix utilities. They do (execute) and say (create output) things as you tell them to do with your script. As the script writer you're most concerned with orchestrating these interactions and controlling inputs and outputs to other peoples' programs.

Contrast with programming where you're concerned more with classes, subroutines, data structures, algorithms and the like. Sure, scripts touch on the above, just as a stage script shares elements with a novel, but not to the same extent. And certainly some projects involve both scripting and programming, and there's nothing wrong with a program calling a script on occasion, but that's not going to be its primary purpose. Sometimes the line between the two might be somewhat fuzzy.

Perl is the best language you can use for scripting, and in many cases the best language you can use for programming. There are more areas of deficiency on the programming side than on the scripting side - Perl 6 addresses many of them.