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 am pretty sure people use Python over C# for more reasons than just taste and C# over Python for other situations.

Stettin

See also #125867 – Soulsearching

Answer 1

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.

Sheena

I've used statically typed and dynamically typed languages extensively, and statically typed ones catch so many more errors at compile time that it is easily worth the extra typing. You make up for type annotations by not having to write so many unit tests. Actually, in languages such as Haskell with advanced type systems, quite often, if your program compiles, it works correctly. (And you don't even have to do type annotations!) – Hamachi

I typically see Duck typing proponents come from a background of working on small systems. Managing the complexity of large systems becomes on of the most time consuming parts of the development process and static typing and compiling along with powerful IDEs are huge boons in this management process. – Disoperation

why was this downvoted? i like this answer. (I will upvote later) – Ceasar

That part about writing tests solves the typing issue for dynamic languages - it's very ideal. In the real world, tests aren't dilligently written by programmers as they should. A bug has to occur first before engineers are forced to write the tests they should have written in the first place. Just a touch of realism here why static languages are still effective when it comes to bugs. It does the heavy lifting for developer's laziness. – Tumbrel

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.

Cremona

Answer 3

1. Flexibility: you don't have to worry about the static type system.
2. Speed of development: an interactive language allows you to write code and test it faster.
3. Built-in types: usually script languages provide dictionaries, lists, tuples, sets, etc. as part of the language (not libraries) with syntax sugar that can be very handy.
4. More dynamic features:
   1. you can "eval" code at runtime very easily.
   2. you can replace on the fly functions and methods.

The main drawback is that those features are often too powerful, and without an strict discipline it's very easy to write code that is unmaintainable.

Clabo

"write code and test it faster" Why the need to test so fast ? Maybe because you are not sure the code will work as expected, because there's no static analysis. With a statically-typed language you can write a whole program without any testing. – Erosion

@Max Toro yes, you can write a whole program from the beginning to the end without testing, and it will be wrong with 99% probability... And static analysis won't help you there more than a spellchecker will do while writing a book. Maybe you're a genious, but most of the people in this world don't get it right the first time. – Clabo

Yes, the probability of bugs will always exists, but with static analysis the number of bugs decreases drastically, you don't have to test each line you write. Also, it's much more powerful than a spellchecker, it's also a semantic checker, you cannot pass an apple to a method that expects an orange, it tells you if what you are writing doesn't make any sense. – Erosion

The semantics are the meaning you want to give to your program, if you want to add to values and you put a * b instead, no static checking in the world will help you with that. And "passing apples instead of oranges" are the easiest problems to spot, you can also write assertions on the runtime types. – Clabo

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.

Benis

Just a slight note on that add-ons bit: with some languages, such as Python, which can use extensions written in C, you DO have to compile/install things in certain situations. – Larner

Initial development time is one of the smallest time sinks in the development process. Maintenance and managing complexity in large systems is a much larger time sink. – Disoperation

@clemahieu: true, but in the imperfect world, we have lots of trade-offs. Many say they write in C# because its quicker to develop in, so the issue isn't solely speed of development, but design time. eg. you can write good apps in PHP if you plan it first, just like you can write poor apps in C# if you rush straight into development. – Benis

Answer 5

Because Python is like flying:

Shona

Answer 6

In my experience two things are the most important decision that you have to make before you start designing / coding:

• What language are you the most familiar with and understand the concepts of it?

There is no use in going with C++ if you don't even get the idea of templates or OOP in general.

• Are there already libraries or tools that assist you?

Imho the most important point, because i.e. you want to code sth like twitter, you can write your own omnipotent webserver in Lisp and hack things like javascript- or form-convenience-functions together - but why no just use i.e. Tomcat/Java/Wicket or respectively Apache/PHP/Synfony? So all the basics are covered, well-tested and with many resources online. Even more you should consider ORM-frameworks/database-wrappers - they save a real lot of time and errors - if you need them.

As a rule of thumb: If you start completely from scratch (i.e. research) pick the language you like most (and ofc is powerful enough for your task), if you do development in an common field (i.e. websites) pick the language according to your skills and the already available tools.

If performance is really an immediate concern, stick with the compiling languages.

Just my $0.02

Imperturbation

That is good and all but i cant imagine using a scripting language over C# (except when you dont have a choice like perhaps for an addon). – Ceasar

Why not? I currently use MATLAB for SVM-stuff, because it has the tools for it. Sure, C# could eventually do the same... but why should I go the extra 20 miles? – Imperturbation

Answer 7

It's kind of been mentioned tangentially, but the question as phrased contrasts 'statically typed' versus 'scripting', and it's a false dichotomy. It's possible to have both, in languages like F#, where there is succinct syntax, type inference, and an interactive REPL. There are some trade-offs and tensions on both sides, but you get a lot of the best of both worlds.

Stettin

Answer 8

Portability to other platforms, and simpler development environment (usually just a text editor, not Visual Studio).

Persona

You don't need Visual Studio to write C#, you can use Notepad if you want - but an IDE helps! – Marylyn

Answer 9

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.

Noncompliance

Answer 10

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

Bearden

Except when it's a dragon disguised as a duck, but that's a different matter entirely. – Larner

English is ambiguous, this is why it isn't used as a programming language. This is also why Duck typing doesn't scale. – Disoperation

@clemahieu: Rather than attacking everyone's answer here, why don't you create your own answer about reasons NOT to choose dynamic language. That will be more helpful to SO and everyone else who revisited this question in the future. I'm not saying that duck typing is good/bad, just that it's one of the reason for people to use dynamic language (as is the question is about). – Bearden