What are the good, the bad, and the ugly of scripting languages?

[Corman]

Here I am again still working on my artical with a new goal for dicussion. What are the good, the bad, and the uglies of using a scripting language? I am looking for talk on generalities here again. Please tell me what is good about using a scripting language, the bad in implimenting it, and the numerous ugly things you cant stand. Thanks again. I know it is a broad and vague question, but as usual that is its purpose to get an unguided selection of thoughts. Thanks again for helping with my research.

-Corman

[soniCron]

The Good Support for "natural" programming:

Automatic conversion to/from strings/numerals
Easy string usage (searching, concatenation, etc)
Dynamic typing
Memory management
Incredibly fast development


The Bad Not negligible to embed or extend:
Usually forced to interact with the script's stack
Typing support in C/C++ limited with limited conversion support routines
Script support libraries not accessible except through stack routines

Not as fast as natively compiled code
Distribution of source common (difficult to obfuscate proprietary script code)

The Ugly Usually wretched debugging interface!!

[Bad Sector]

the bad is that some parts are hard to implement, namenly the garbage collector, local variables in functions and the expresion parser. The expresion parser is the easiest from these, then local variables come and lastly the garbage collection which can be a total pain - especially if you want a fast one.

[luggage]

Another bad. If you're going to be the one to write the scripts then you may as well just save yourself a huge bunch of time and not bother with a scripting language.

This is presuming you're not implementing the scripting language so end users can extend it or something.

[Bad Sector]

I always founded it easier to write scripting code than C/C++ code (given that a nice API is exposed to the scripting engine of course). This is why when i wrote Nervebreak (http://nervebreak.sf.net/) i was adding scripting to almost everything i was writing :-)

[illume]

Because of the wide variety of scripting languages you can choose one for your task. Not all scripting languages are created equal. So for example in python it is simple to do a bunch of things which are hard in other languages. Likewise other scripting languages are better at other things.

So you can chose the scripting language best suited for your tasks and then possibly avoid the problem areas.

You can generalise things, but then you will be wrong and missleading for some things. So perhaps your article should preface your generalisations with: 'Some scripting languages have these good points, and these bad points, and others do not.'



Which is faster?
- a program done in a scripting language with primitives optimized in asm and a runtime optimized specialising compiler.
- or a program compiled with C?
- a scripting language with a basic VM with no support for native machine code, with no C/asm optimized primitives.

Which is easier to use C libraries?
- python, the easy ctypes way.
import ctypes
somelib = ctypes.cdll.LoadLibrary("some_lib.so")
some_lib_function()

- C the easy, non runtime loading way.
#include <some_lib_header.h>
some_lib_function()
gcc -lsome_lib yourmain.c
- another scripting language.
< insert 10-100 lines of C code to wrap one function. >

Obfuscators, and byte code can make some scripting languages just as hard to comprehend as C compiled to machine code.

Debugging in some scripting languages is very advanced. Such that you can do things like change classes, functions etc at run time. You can even save the runtime state of the program for later inspection. Other scripting languages have no debugging support at all, and rely on printing, and tracing variables. However using print statements can often be good enough.

Some scripting languages require different syntax to C/C++. This is good and bad. Good because the C/C++ syntax can be simplified to be easier to read, modify, and create. Bad because it is harder to translate algorithms to and from the scripting language without C/C++ syntax.

[Corman]

Very good point illume and I thank you for bringing it up. Personaly I know this, and always have it in mind, but I completely forgot to take this stance when I was writing. My article deals with scripting languages, but is scripting language agnostic. It deals with an approach theory that uses scripting languages as its foundation, but does not care about what scripting language it uses. The implementation of the lowest part of this thoery with the scripting language is left as project for the reader, but will give examples using other scripting languages. The rest of it really doesnt care. Thats why I have been asking in generalities, and it is hard to gets answers because of this. But thanks again illume, you really have helped me by giving that kick in the butt to reread what I have been writting and see that I did leave out a good part of the story. What I have been asking about is for warm up on what is scripting, the good and the bad, general talks about where it is useful, etc. Basically, even though it sounds bad to say so (no other simple way to say it), it is the fluff and filler stuff. Please keep things rolling, and thanks to everyone else too.

-Corman