views:

392

answers:

8

Assuming you can get a dynamic interrupter; can statically compiled languages replace scripting language? I never quite understood why anyone would use a scripting language? I am talking about on PC, not a limited system which needs a simplistic interrupter. I seen some python install scripts and seen similar python and C# solutions to a problem. So why use a scripting language?

NOTE: There are things that bother me about C#, i am not asking why not use C# instead. I am asking why use a scripting language? I find static compiled languages much easier to debug and often easier to code in.

+1  A: 

Wikipedia says that a Scripting Language is a language that controls other software. You can do that with C#, but true scripting languages like Powershell are designed specifically for this.

I tend to think of a scripting language in more "interactive" terms than C#. With a scripting language, you can write a line or two of code, execute it and see the results immediately. That's not so easy in C#, where you have to put your code in a Console Application, or fire it off from a unit test, or type it into the Immediate window where you don't have intellisense.

That rapid cycle of write, execute allows rapid prototyping of complete "scripts" in a scripting language, because it gives you immediate feedback on each line of code.

Robert Harvey
doesnt C# take almost the same amount of lines as a scripting language? When i ported one of my python scripts the actual function body was pretty much the same amount of lines. (it depends if i want to stuff a single line with(statement()))
acidzombie24
+2  A: 

This kind of question often starts flame wars as people are passionate about their respective camps.

In the computer olden days, Unix command line tools and console shells provided a rich scripting environment where all sorts of processing could be done. You didn't need to be an expert programmer in any specific language and could string (pun intended) various programs (other people wrote) together using the pipe structure to massage your data which was mostly text not binary related. It is quick and easy to make changes to your batch command file. You don't have a source file that has to be edited, compiled linked with external static or shared libries/DLLS in the case of Windows.

One thing scripting does not have normally have is speed. You don't write device drives and live internet trading AI systems in scripting. But if you run a script once a day on some data received via e-mail or ftp you don't normally care how long it takes as it can run it background anyway.

Rewind back to the present and the waters become muddy. Some scripting enviroments offer a kind of speed up facility where they will read you script and almost compile and link in modules the same a normal C++ or VB program might use for speed puposes. But this very iffy and can't be relied on.

So how do you choose which route to go. Start doing tasks using scripting. If it runs too slow or you are having to do stuff every 5 minutes then parts of your script might benifit from a section written in a traditional language or the whole thing could be written in a language.

Like anything dabble and learn

+1: Except the real "computer olden days" predates Unix and things were much more painful!
Don Roby
+1  A: 

Each is used for different purposes. Programs written in scripting languages are often not self-contained; they often function as "glue code" or (as Robert Harvey mentions) to automate a task. You often find scripting language interpreters embedded within an application (cf Python in Blender; Guile, Perl and Python in GIMP; JS in umpteen different browsers; Lua in countless games). Compiled languages, on the other hand, are used to produce self-contained applications. Scripts are mostly cross-platform; compiled applications usually aren't.

Note that a scripting language doesn't necessarily use an interactive interpreter (e.g. Perl), and an interpreted language isn't necessarily use for scripts (e.g. games made using PyGame). Note also that there's nothing about the languages themselves that make them interpreted or compiled. You could have a C# interpreter or a Ruby compiler. There have been a number of Lisp systems that offered both interpreters and compilers.

outis
A: 

Because it is shorter to write since it is a higher level language, and it doesn't need the compilation cycle which also makes thing shorter.

programmernovice
Ever seen the speed of the haXe or C# compiler? for script size projects it's superfast. with the profit of being faster at runtime.
Dykam
+6  A: 

There is very little distinction these days between compiling and interpreting. Look at how an interpreted language is executed - the first step is to convert the script into some kind of internal executable form, like byte code that can be executed by a simpler instruction set. This is essentially compilation to a virtual machine format. This is exactly what modern compiled languages do. And when compiled languages are deployed in server-side web apps, they even recompile from the source on the fly. So there's practically no difference in terms of the compile/execute technique.

The only difference is in the details of the instruction set, specifically in the type system. Scripting languages are usually (but not always) dynamically typed. But many large applications are also written in dynamically typed languages too. So again, there is no clear distinction here.

Personally I think static typing, far from being "extra unnecessary effort" (as it is often described) is actually a huge productivity booster, making it much easier to write short snippets correctly on the first attempt, thanks to intellisense/autocompletion. To underline this, look at how Microsoft has improved the jQuery library simply by adding static type information to it (in specially formatted comments) so we can have intellisense in the IDE.

And meanwhile, static languages (including C# and Java) are bringing in more dynamic typing features.

So I see these categories as eventually merging and the distinction being meaningless.

Daniel Earwicker
C# and java are not bringing any dynamic typing features. Scala has support for kind of duck-typing in a sense that you don't have to create an interface which you are using as a type, but rather say that you expect to have a class with method of certain name and type. It is true that you can mimic dynamic typing on a statically typed language by passing only top-level base objects around and checking the contents at runtime, but you can't do it the other way around by getting interpreter to enforce correct use of types.
JtR
Maybe you want to read about C# 4.0. (Also the JVM in Java 7 will have a dynamic method invocation instruction in bytecode, perfect for building dynamic langauges on top of the JVM). Also in my actual answer I give the example of static typing being added to jQuery, a JavaScript library (a dynamic language).
Daniel Earwicker
static typing was not added to jQuery, you said it was in specially formatted comments which don't affect the runtime or compile time behaviour of jQuery, merely static analysis. This is static annotation and not static typing.
barkmadley
+1  A: 

Before we begin, I don't think that I've ever met a static language user who "got" scripting language without trying them, including myself. It is a different experience.

So no. Basically, you can add features to static languages which makes them superficially seem like scripting languages (like simple type inference), but its not the same:

  1. Many scripting language users hate static languages. They feel constrained. Scripting languages are typically very good at not getting in the users way, which is sacrificed in static languages for speed/correctness.

  2. Duck typing will not appear in static languages.

  3. Scripting language users don't like type annotations. Its not really possible to provide a type-inference system for scripting languages, and the simple type inference appearing in some languages now only works for static types.

  4. Techniques like monkey patching (which to my mind is a very bad idea) is pervasive in Ruby, and allows for very powerful techniques, which won't become available soon in static languages either.

Which isn't to say that a yet-to-be-designed language can't handle scripting language features in a relatively static way, but it would be difficult for it to become popular relative to the entrenched Python/PHP/Perl/Ruby/Javascript set. Factor is the closest thing, AFAICT.

What will happen is that scripting language implementations will get faster by using JITs.

Paul Biggar
A: 

I am asking why use a scripting language? I find static compiled languages much easier to debug and often easier to code in.

Because I find loosely-typed dynamic languages without an explicit compile-run cycle much easier to debug and generally easier to code in.

Dave Sherohman
+1  A: 

Can a screw driver replace a hammer ? No, because you just don't use them for the same purpose. And if both exist, and if such a lot of people use either one or the other, there must be a reason...

Same anwser for :

  • class inheritance vs prototype;
  • imperative vs oo;
  • static vs dynamic typing;
  • strongly vs weakly typed;
  • manual memory management vs GC;
  • C# vs Java;
  • blue vs red;
  • man vs woman;
  • batman vs superman (but I do think superman would win... wait, there is kryptonite... oh man, I don't know...)

etc...

e-satis