Scripting languages

Question

What is it about scripting languages that makes them so easy to do rapid prototyping? Is it just that they are not statically typed?

I am a C# programmer, and have had not much experience with javascript or python .. or any of the other scripting languages out there.

The more i read about them the more i feel that they may be the answer to some of the problems i run into when i need to get a quick prototype ready for a "proof of concept"

Answer 1

I think it's all the code you aren't writing, and how laser-focused you can be on your problem and its solution.

Your code has elements in it primarily for two purposes. First is the solution to your domain problem. Second is making your compiler/interpreter happy.

This became clear to me when I was writing code simultaneously with javascript and actionscript, because actionscript is basically javascript with all the declarative overhead. The difference between the two is exactly what you're describing. It's kind of like a form of signal-to-noise ratio. How much lf your work goes to solving your problem vs. how much goes to working on your tool?

Answer 2

ORM for one can be very easy when your variables are dynamically typed. The syntax of scripting (higher-level in general) languages can be more minimal and forgiving as well. At the end of the day though I think you will be most productive with the languages you know well.

Answer 3

For me, the single feature most conducive to rapid development, which most scripting languages have and most compiled languages do not, is the ability to break the application while it is running, change the code, then continue running without losing the existing state of all the application's objects and variables.

Answer 4

Jeff Atwood had a post on Coding Horror just a couple days ago about this. Mind you, I think dynamic typing and do-what-I-mean are the most evil things in the programming world (anything that puts off detecting an error until run time is bad, IMHO), so I disagree with most of his post, but it is informative nonetheless.

Answer 5

I hear this a lot too.

I've never understood the prototyping argument for scripting. Don't get me wrong, I like scripting languages, but I just don't see how you're proving something is possible when you write it in a language you won't end up using. You might as well just write psuedo-code.

For example, if I write something in javascript then I don't have access to the .net library. This is a big deal if I intend to write the program in C#. I find that the libraries you use can have a big impact on your code; and thus on your prototype.

What is it about scripting languages that makes them so easy to do rapid prototyping?

I don't think anything about scripting languages makes them easy to do usefull prototyping. Personally, I prototype as close to the real thing as I can. I find this to be the best way to determine if something's possible.

Answer 6

Scripting or more accurately dynamic languages have several aspects to them that make rapid prototyping painless. First off they are weakly typed so aer vey forgiving if you want to use an int as a string or vice versa. They have a much more rapid code, compile, test cycle since the compile stage is virtually removed. They also tend to have constructs that make coding more like your thought process. I'm thinking of grep, map, inject (in ruby), lambda functions, anonymous functions etc.

Answer 7

The good thing.

You don't spend time compiling.

The bad thing

You don't get help from the compiler for naive errors.

Scripting languages are terrific for quick things. And even good enough for larger ones. But when it comes to team development where not everyone has the experience to detect or understand something as simple as "null pointer exception" the compiler makes a difference.

Answer 8

1. Memory management is magic in PHP/Ruby

2. Pointers are wrapped and almost completely handled with atomic reference management

3. No compile time

4. Higher level of execution leaves room for easier hook entry for debugging

   I've been using scripting languages for over a decade now and I've found the winning combination with using them is as glue for more powerful dynamically linked/integrated machine code like c/c++. Kind of the direction Microsoft is/was going with its activex dll's and such, but without Microsoft involved.

Answer 9

Two words: instant gratification.

Joel talks about this in the Joel Test of working conditions:

Here's the trouble. We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment ... The trouble is, getting into "the zone" is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity ... The other trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers -- especially interruptions by coworkers -- all knock you out of the zone.

As a long-time Java programmer, one of the things I like about PHP is that seeing if something works is as simple as clicking 'Save' and then hitting reload on my browser. I instantly see if it works or not.

Now if I have to do a build (which might take 1-15 minutes), deploy (anything from 10 seconds to a minute or two) and restart my appserver (another 30 seconds or more depending on complexity) then I've lost my train of thought ("dropped out of the zone").

Another poster mentioned Jeff's column about this and it's along the same lines.

Scripting languages are good because when you get instant feedback you are more productive.

Answer 10

You simply write less code in a scripting language then you would in c#. It's amaizing how much smaller things are when you take out all the variable declerations, required class declerations, etc. I also find scripting languages are more productive for me since I'm a text editor instead of IDE user. Not having to go back to a command prompt and enter a command to recompile may only save two seconds each run of your program but that adds up.

Answer 11

Speaking generally, several things come to mind:

• The read-eval-print-loop (REPL) lets you quickly iterate over small blocks of code. With something like Emacs, you can often make a quick fix to a function, send the updated version to the interpreter with a key stroke, and then jump to the interpreter and test it out. And this without losing the current program state.

• Higher level coding. Language-level support for hash tables, lists (and list comprehensions), etc. makes the barrier to using them very low. Code tends to be much more concise than using library versions of them.

• Blurring of data and code. If you've got a table of constants to initialize, you can usually just write it out directly. Would you rather write something like:

  constants = {"Pi": 3.141, "e": 2.718}

  or something like

  HashTable constants = new HashTable();
  constants.insert("Pi", new Float(3.141));
  constants.insert("e", new Float(2.718));

  The discrepancy only gets more pronounced with more complex structures.

• Dynamic typing. No need for type annotations or to spell out the types of each piece of data in your structures. This also leads to things like duck typing, where there's no need to write interface boilerplate. You just call a method and it either works, calls a fallback or triggers an exception.