# What is the difference between a scripting language and a normal programming language?

What is the difference between programming language and a scripting language? For example, consider C versus Perl.

Is the only difference that scripting languages require only the interpreter and don't require compile and linking?

• I'm afraid this is offtopic here; what you want to know is purely a matter of language implementation. It also seems to attract shallow/opinion answers (not your fault per se), which is always a red flag. – Raphael Aug 16 '12 at 7:30
• Hardware is an "interpreter" for compiled languages. The only difference, then, is how many interpreters you're going through. If the machine is Turing equivalent and you're using a language which is Turing equivalent, you could write a compiled interpreter A in the language, then write an interpreter B in the language that interpreter A can execute, then an interpreter C in the language that interpreter B can execute, etc. Essentially, it's all a matter of indirection, which has less to due with theoretical basis of computation and more to do with practical engineering concerns. – Patrick87 Aug 16 '12 at 15:43
• Salaries (pre-DevOps) – Phil Lello Nov 26 '16 at 0:07

I think the difference has a lot more to do with the intended use of the language.

For example, Python is interpreted, and doesn't require compiling and linking, as is Prolog. I would classify both of these as programming languges.

Programming langauges are meant for writing software. They are designed to manage large projects. They can probably call programs, read files, etc., but might not be quite as good at that as a scripting language.

Scripting langauges aren't meant for large-scale software development. Their syntax, features, library, etc. are focused more around accomplishing small tasks quickly. This means they are sometimes more "hackish" than programming langauges, and might not have all of the same nice features. They're designed to make commonly performed tasks, like iterating through a bunch of files or performing sysadmin tasks, to be automated.

For example, Bash doesn't do arithmetic nicely, which would probably make writing large-scale software in it a nightmare.

As a kind of benchmark: I would never write a music player in perl, even though I probably could. Likewise, I would never try to use C++ to rename all the files in a given folder.

This line is becoming blurrier and blurrier. JavaScript, by definition a "scripting" langauge, is increasingly used to develop "web apps" which are more in the realm of software. Likewise, Python initially fit many of the traits of a scripting language but is seeing more and more sofware developed using Python as the primary platform.

• +1 for the real-life example: I can't imagine being forced to use C++ to perform batch-rename tasks! – Casey Kuball Aug 16 '12 at 4:44
• You don't state any conceptual differences, only popular opinion about the respective use cases. – Raphael Aug 16 '12 at 7:33
• Would you also "not write" world's largest social network in scripting language (FB in PHP), one of the first blogging services that promoted entire trend (LJ in Perl), version control system that easily allows thousands of developers to work together (Mercurial in Python)? Sorry, but this "scripting is for small tasks" is just popular buzzwordy rubbish. – Oleg V. Volkov Aug 16 '12 at 10:57
• @Raphael I think the conceptual differences are fuzzy at best. The main difference is in popular usage, IMO. Most of these languages will all be Turing complete and follow a similar model of computation. I've never run across a formal distinction or definition, but feel free to edit my answer if you have one. – jmite Aug 16 '12 at 16:15
• @Raphael That's part of the point: there are no conceptual differences. What you can do at compile- vs run-time is a primarily a matter of interpreted vs compiled, and that's a property of the implementation, not the language (though the language design can make a particular implementation model difficult). – Gilles 'SO- stop being evil' Aug 17 '12 at 18:06

The classic article on scripting languages is John K. Ousterhout's Scripting: Higher-level programming for the 21st Century, published in Computer 31 (3), 1998. He drew a distinction between scripting languages, on the one hand, and system programming languages on the other.

Ousterhout characterized system programming languages as having evolved to replace machine languages for programming. They hide tedious details like register assignment and subroutine calling sequences, provide simple constructs for writing loops and other common control-flow idioms, and enforce a typing discipline. They are usually implemented by an (ahead-of-time) compiler. These languages are meant for writing software from the ground up. Examples are C, C++, and Java.

In contrast, scripting languages, according to Ousterhout, start from the premise that there already are useful programs out there, usually written in system programming languages. Scripting languages, like Perl, Python, Tcl, Visual Basic, and the Unix shells, provide tools for combining these existing programs into new programs. Ousterhout characterized scripting languages as "typeless" (including what many call dynamic typing), and as emphasizing rapid development; they are usually implemented by interpreters.

Now, one must be careful not to assume that a single author's conceptual model is authoritative. Even though we computer scientists like to pretend we are mathematicians giving precise definitions to all terms, in practice most computing terminology is socially constructed with fuzzy and heterogeneous meanings; there is a rough consensus in a very high level about most terms, but details often depend on who is writing. Thus, take his article, my answer, and all the other answers here with a large heap of salt.

I would personally dispute the existence of a "normal" programming language, as you phrase it in your question. However, I think the concept you are trying to convey corresponds roughly to Ousterhout's system programming languages.

All scripting languages are also programming languages. The converse is not true. Languages that "require only the interpreter" are interpreted languages (as opposed to a compiled language -- note that some languages, such as Java, fall into both categories).

A language being categorized as a scripting language implies that it is useful as a "glue" language. Scripts do not tend to be full-featured programs, but instead fill in the gaps between other pieces of software.

Scripts are usually used to connect multiple programs together, to perform menial tasks very quickly/easily, or even in an embedded environment where performance and safety concerns have been abstracted to a lower level language. Scripting languages emphasis tends to be on reducing development time, hence the reason most are interpreted and very high level.

• You don't state any conceptual differences, only popular opinion about the respective use cases. – Raphael Aug 16 '12 at 7:33

Set 'scripting languages' is subset of set 'programming languages'. The difference between C and Perl is difference between system programming language and application language and between interpreted language and compiled language.

System programming languages are low-level and oriented toward memory management, predictable IO and so on. Application languages are oriented toward quick resolution of higher-level problems, like 'read setting from file , open socket and process requests according settings'.

Thus, application languages tend to be much higher-level, then system languages, i.e. provide great amount of built-in abstraction and helper facilities and often adds automatic memory management of some sort.

Programs in compiled languages are processed to some code completely before program execution. Scripting languages are translated dynamically in process of execution and often include facilities for dynamic code generation and including files with source code.

Thus, all scripting languages are application languages, but opposite is not true. System languages are always compiled languages, as scripting languages usually include features, that are not pragmatic to implement in terms of the language itself. Note, however, that scripting(interpreted)/compiled difference is more about implementation: for some languages both types of implementations may exist, as for haskell.

• I think it's a fallacy to draw this interpreted/compiled dichotomy. I also don't think it's a subset relation, though certainly the sets have some non empty intersection. Likewise, high and low level don't know accurately describe the distinction. Prolog is very high level, but is not a scripting language the way bash or java script is. – jmite Aug 18 '12 at 23:11

Others have covered attributes that tend to be associated with scripting languages and with non-scripting languages. That's helpful for getting a feeling about what people mean when they use the term "scripting language", but I feel it's more important to understand that there is simply no neatly defined boundary: Two knowledgeable people could disagree about whether a particular language X is a scripting language. The term "scripting language" nevertheless has utility because there is broad agreement about languages that are far inside, or far outside, the boundary.

Compare "family car" vs. "sportscar", or "magazine" vs. "newspaper". I daresay that it would be difficult to come up with a 100% reliable rule to differentiate every family car from every sportscar that is generalisable (meaning that it does not basically amount to enumerating all existing cars in each category) and at least potentially objective (meaning it would be acceptable to everybody). But these terms are still useful in practice, because although there are some cases that are hard to decide, many cars are clearly in one category and not the other.

A difference I haven't yet seen mentioned is that when used as intended, the execution time of most scripts will be dominated by "macroscopic" operations, and the performance of microscopic operations will not have a significant effect on overall execution time. For example, if a ray-tracing animation program might include a scripting language with a "render image" statement, a script to produce 240 frames of animation might spend four hours in the "render image" statement, and a total of four seconds doing everything else. Even if one were to speed up everything outside the rendering engine by a factor of a million, that would have less effect on overall performance than speeding up the rendering engine by 0.1%.