posted by Ritesh Kumar on Thu 13th May 2004 19:31 UTC
IconIn recent years "scripting languages" are becoming a path which is a must go for rapid application development. The open source community has seen many scripting language implementations. Some really popular and good ones available are perl and python.

I recently had a pretty good discussion about this with one of my friends on chat. Mary was trying to find out about type systems in general and the basic classification of languages in terms of the typing system they use. The following is a summary of what we discussed and finally concluded upon.

The major reason why scripting languages exist these days is because it is easy to develop using one. Most scripting languages don't enforce type declarations of the variables which relieves the developer from supplying the type of a variable every time he declares it. Scripting languages often feature a very rich set of primitive data structures which can be operated upon easily by using very concise syntax. They also feature a huge library repository so that the developer time is cut down.

These were more like the "language inherent" features of a scripting language. Scripting languages also have another notable common aspect which is of the way they are implemented. Almost all scripting languages are interpreted. Often, in popular use of term, "scripting" is generally attributed to an interpreted language implementation rather than one which has language features like the ones shown above. However, this might be incorrect to say if we adhere strictly to the "ease of programming aspect" of scripting languages as their compelling feature.

Personally, I give a lot of importance to efficiency. That means I am not glad to see slow implementations of good scripting languages. However, I also understand that these days programming throughput is so important that people are willing to sacrifice efficiency for gains in programmer productivity. This brings us to an important question. Does programmer productivity imply an interpreted or slow implementation of the language? Programmer productivity depends on a number of things

- The ease of use of the language (availability of high level data structures and operations, relaxation of type declaration)
- Lesser learning curve for the language itself
- As a (though not a very avid) developer, I have seen that the major amount of learning curve that I face is from learning new APIs for different languages. Often getting used to the libraries of a language is more demanding than learning the language itself.
- An easy way to integrate native (harder but more efficient) languages to the scripting language. One may think of the scripting language API in a low level language like C to be the bridge used to do the same.

It should be noted that none of the above features actually imply that the language implementation be interpreted. Often the meta-hacking and introspection demands in a scripting language are high. However, even this amounts to a powerful runtime of the language and doesn't necessarily imply an interpreted language implementation. In fact, the very fact that scripting languages and native languages are so diverse offer rest of the three problems to a programmer.

Mainstream programming languages have also come far from the times of the assembler and C. Nowadays languages sport constructs for object oriented programming, sometimes even syntactic sugar for commonly used primitives (C#?). Languages like OcaML feature a very rich type inference mechanism which does away with the need to supply types at all. This is like scripting languages with typeless variables except that in scripting languages the types are checked at runtime whereas in OcaML it is statically checked, making the final compiled program faster. Advances like these show that it is possible to keep an efficient implementation of the language even if the language has scripting language like features. Languages like Java have a really powerful runtime which enables programs to introspect existing data structures and what's more, even create custom types while the program is running. Language features like these go a long way to support better software engineering practices and increase productivity.

It is in fact possible to eliminate the other three hurdles in programmer's productivity by implementing a well designed language system. Why do I call it a language system? It is because, most often than not scripting languages are used to glue together natively implemented components. Thus libraries of the scripting language are native, but the program is made in the scripting language. Sometimes, scripted components are called from inside the native application. All this motivates a good amount of interoperability between the two languages and that's where the API for the scripting language in the native language comes in. This bridge should be easy to use. In a well designed language system, this bridge can also be entirely eliminated. The best example of such a system that I can think of is BeanShell/Java. The BeanShell scripting language is an adaptation from Java itself except that it has the features of a scripting language like typeless variables and syntactic sugar.

Table of contents
  1. "Scripting Languages, Page 1/2"
  2. "Scripting Languages, Page 2/2"
e p (0)    85 Comment(s)

Technology White Papers

See More