What are reasons to choose a scripting language over C#?

Question

What are reasons to choose a non DSL scripting language over statically compiled language such as C#?

-edit- Good answers so far. I feel I should explain further. I

Answer 1

I would like to add another point to the list: user defined logic.

If you write a software where the user is supposed to define some logic for the program to work, scripting languages like Python are the ideal choice. Use cases include things like, e.g., mission scripting for games, statistical evaluation of a data set, and mail filters. To setup a complex filter rule, you do not want your user to start up Visual Studio to compile some code into a DLL and then load the DLL as a plugin, you just want the user to provide some textual definition of the filter that defines the filtering logic.

When your software is written in a scripting language, including user written code is usually trivial.

Answer 2

Scripting languages excel primarily in 2 areas:

1. Small to medium sized projects where performance is not a top priority and flexibility in the runtime enviroment is.

2. The construction of domain specific languages. The duck typing, dynamic method invocation capabilities of a scripting language make it ideal for designing domain specific languages. Ruby on Rails, of course, is the poster boy for this capability, but numerous other examples exist especially in proprietary in-house developed software.

Answer 3

Because Python is like flying:

Answer 4

Speed of development generally, a script language removes any need to compile anything - just type away and execute it. Generally, you can type away as it runs if you edit it whilst you've stopped it in a debugger - no recompile, no need for 'edit and continue' support, no nothing.

Many script languages also have less restrictive scope for things like static types, you can just code without worrying whether your string needs to be converted to an integer or vice versa, you just use it as-is and it works. It's debatable whether this is a good or a bad thing, but I reckon it's one of those things where it's good when used for some tasks and bad for others.

Add-ons and libraries are also generally much easier to use - you don't need to register or install anything, or worry about assemblies or the GAC or signed stuff, you just include the source files and you're done.

So script is the easiest thing to make work in general, that's why people use it.

Answer 5

Duck typing: if it walks like a duck and talks like a duck, it is a duck.

Answer 6

Programmers who have only used a statically typed language may just accept that that's a necessary way of doing things. Once you experience duck typing, you realize that polymorphism can really be just that simple - without all the extra lines of code to specify types.

All that type declaration stuff is not required for the program to work - and this is liberating to experience - it is merely so the compiler can check for certain types of errors.

If you don't do testing in a dynamic language, you can get hit by run-time errors that the compiler would catch in a statically typed language - but it turns out this is not as much of a win for statically typed languages as you might think, because you should be doing testing in both types of languages anyway. You need to test in statically typed languages to catch the other logical errors that the type checking won't catch - and in many cases, those types of tests passing would rule out the type related errors anyway - so you don't need enough extra testing in dynamic languages to offset the type declaration coding you don't have to do.

The result is not just increased productivity, but the pleasure of just focusing on what you want to do, the crux of the problem, rather than getting bogged down in telling the compiler a bunch of stuff so it can protect you from errors you're going to (should, at least) test against anyway.

Performance is the tradeoff, since a dynamic language can't assume so much at run time - but a lot of times performance is not the issue. And when it is, you can rewrite the performance critical modules in a lower level language. Languages like Python make this easy.

Languages with type inference capabilities are a middle ground worth considering.