There is no such thing as a language that must be compiled by a compiler first. Compilation and interpretation are traits of a compiler or interpreter (duh!) not a language. Every language can be implemented by a compiler and every language can be implemented by an interpreter. There are interpreters for C and C++, for example, and there are compilers for JavaScript, Python, PHP, Ruby, Perl, Lua, Groovy, Boo, etc. In fact, all mainstream JavaScript, Python, PHP. Ruby, Lua, Groovy, and Boo implementations and at least one Perl one have at least one compiler.
– Jörg W MittagDec 9 '18 at 22:54

3

Okay, you're just being VERY nit-picky with my choice of phrase "compiled languages". Of course languages by themselves cannot be compiled. What I meant by a "compiled language" is a programming language such that a PROGRAM written in that language needs to be compiled. I NEVER SAID THE LANGUAGE ITSELF NEEDED TO BE COMPILED. Don't derail my question!
– Niko GambtDec 9 '18 at 22:57

2

"What I meant by a "compiled language" is a programming language such that a PROGRAM written in that language needs to be compiled." – As I already explained in my last two comments, this definition does not make sense, because whether or not a program written in a language ends up being compiled or not is a trait of the compiler or interpreter used to implement said language, not the language. According to your own definition: "a "compiled language" is a programming language such that a PROGRAM written in that language needs to be compiled", there cannot possibly be such a thing as a …
– Jörg W MittagDec 10 '18 at 1:39

2

… "compiled language", since a program never "needs" to be compiled. I can always implement an interpreter for the programming language. Case in point: according to your own definition, C is not a compiled language, since C programs don't "need to be compiled" as is evidenced by the fact that there are C interpreters. Likewise, C++ is not a compiled language, because C++ interpreters exist. IBM's VisualAge for Java IDE used to contain an interpreter for Java, so clearly Java programs don't need to be compiled, ergo, Java is not a compiled language. On the other hand, all currently existing …
– Jörg W MittagDec 10 '18 at 1:42

2

… JavaScript implementations contain at least one, if not multiple compilers, so does that mean that by your definition, JavaScript is a compiled language? (This is not a rhetorical question, I truly do not understand all the nuances and ramifications of your definition).
– Jörg W MittagDec 10 '18 at 1:43

3 Answers
3

Scripting is automation. Scripting languages were specifically developed for automation tasks. They often have features that make scripting easy, e.g. simple mechanisms for invoking other programs or a less strict language (usually, no type system, or no requirement to declare variables, built-in collections, …). E.g. Perl was designed to “make easy things easy and difficult things possible”.

The language runtime of a scripting language often comes pre-installed on target systems, making development and deployment of these automation scripts trivial: just plop a file into this folder and you're done. For example: Shell, Perl, and Python are widely available on most Unix and Linux operating systems.

Compiled languages tend to be different: their languages are often geared towards “serious” programming that involve larger projects. E.g. Java requires substantial boilerplate for even the simplest program. You'll also have to install the toolchain first, and have to compile the code before running it. None of this is insurmountable, but it's a series of extra hurdles.

Of course, the barriers between scripting languages and real languages have completely disappeared by now:

JavaScript, a browser scripting language, is now used for serious server-side development. Using it tends to involve so much extra build tools and tooling, it puts any other language to shame.

Java isn't the only language that runs on the JVM. For scripting tasks you might use Groovy.

Python and PHP are used for huge projects and by now have type systems and OOP support that surpasses that of Java.

Why should compilation be a hurdle? Many traditionally compiled languages including C, Go, and Haskell have interpreters available, or wrapper scripts that just compile the program on the fly (cint, runhaskell, gorun).

In some circles, it's a serious suggestion that you should use Go instead of Bash for your scripting tasks! That's kind of insane – the two languages do not target even remotely similar tasks – but given the available tooling it's absolutely possible and under some circumstances perhaps even sensible to do so.

Thank you for the respectable answer and for not getting so hung up with trivial definitions. Now that you explained it, the "less strictness" makes sense for automation.
– Niko GambtDec 9 '18 at 23:42

I wish to point out that scripting languages are just as formal as any other language. They just operate with a different set of abstractions, which gives rise to them being type starved in some senses (many are purely text/stream based), but also flexible in others (such as the value being typed, not the variable). These trade-offs are picked with the specific intention of easing automation in their particular environment, allowing more focus to be on orchestration.
– Kain0_0Dec 10 '18 at 3:03

less strictness makes sense for automation. Don't oversimplify things. I would not consider automation made insh to be "less strict" than the same made in Java. It's a matter of suitability or adequacy. Many of the automation doesn't need all the abstractions and capabilities some languages as Java or C++ provides and, of course, they can do without their burdens. It will depend mostly on the nature of the task to be automated.
– LaivDec 10 '18 at 8:25

I don't think there is such strict rule. If the platform naturally supports compiled language it can be used as well. For example, I often use C# as a "scripting" language for Windows automation.

I can point out only one practical difference - as automation tasks are often ad-hoc and, when it comes to multiple people working together, some of them leave some come, it may happen so that you find your important processes depending on a binary with unclear origin, which no-one knows how to modify. When your binary is the source it prevents such risk.

The lines between "compiled" and "scripting" are rather blurred, but if you look at the extremes, like C in one end and Bash at the other end, it is obvious they are optimized for different kinds of tasks:

Advantages of C:

can be extremely fast

close to the metal

Disadvantages:

Complex to learn to use correctly

easy to crash your computer

slow turnaround when developing and testing.

Advantages of Bash:

optimized for one-liners or short programs

extremely quick turnaround with interactive development

designed for integrating with all kinds of systems.

Disadvantages:

rather slow

not really designed for larger programs, may turn hard to maintain

Note that the advantages of C are not important when automating systems. If performance is an issue at all, the bottleneck is probably not the automating script itself. The resource use of the script will most likely be insignificant compared to the application which is being scripted.

Automating scripts typically are not very complex, so maintainability issues of larger Bash scripts does not come into play. This is almost true by definition: If a program does contain a lot of complex logic in its own right, we don't call it an automation script.

So it is not really that compiled languages can't do the same task as scripting languages, it is more that it just quicker and safer to solve the same task using a scripting language.