To automate tasks, I have only heard of people using scripting languages.

Why don't people use compiled languages to automate tasks?

What can scripting languages do for automating tasks that compiled languages can't?


Let me be clear with these phrases:

By a "scripting language", I mean a programming language such that a program (or script) that is written in that language can be executed by an interpreter. The script needs not be compiled.

By a "compiled language", I mean a programming language such that a program that is written in that language must be compiled before the program can be executed.

closed as unclear what you're asking by gnat, Thomas Owens Dec 10 '18 at 13:30

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    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 Mittag Dec 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 Gambt Dec 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 Mittag Dec 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 Mittag Dec 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 Mittag Dec 10 '18 at 1:43

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 Gambt Dec 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_0 Dec 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. – Laiv Dec 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


  • 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.


  • 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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.