posted by Ritesh Kumar on Thu 13th May 2004 19:31 UTC

"Scripting Languages, Page 2/2"
However, since the languages are inherently the same the system attempts to completely do away with a bridging API. Thus BeanShell scripts can run in the same runtime as the native Java program itself. They have completely interoperable objects and methods. So an object in BeanShell can be thought of as a normal object in Java and vice versa. There is no API required because the BeanShell scripting engine takes care of making objects in BeanShell interoperable with those in Java using Java's powerful reflection mechanisms. Now let us see what does this system give us. Learning curve for the language? Very little as it is an adaptation from the native language we are anyways supposed to know. Learning curve for libraries? None, as it has the same library suite that Java has except that now it is available from a language which is easy to program in. Learning curve for the bridging API? None again as there is no bridging API! However, BeanShell/Java is not a very perfect system for the following reason.

Java is a neat language and there have been claims that it runs fast enough to be compared to C/C++. However, it still has a large memory foot print and high startup times. The complaint is more against Java than BeanShell. Current implementations of Java still rely on a Java runtime to C runtime bridge for most system calls. It would have been better if Java was directly used for interfacing with the OS... just too many issues to discuss here.

BeanShell doesn't give any high level convenient data structures like other scripting languages. It would have been great if BeanShell had syntax for directly manipulating data structure classes in the Collections Framework. Some more operations could also be automated. This might result in some form of a bridge API emerging. However, it will never be a bridge between the two languages. It would be a bridge between high level data structures only.

BeanShell is interpreted and slow when it might have chosen not to be. Perhaps it was in the interest of BeanShell (designed to be embed-able in Java applications) to be implemented in Java itself and exploit reflections through the Java API. It might have chosen to compile the script to bytecode on the fly and then run it. However, this is not the goal of BeanShell. BeanShell is supposed to convert a script into some data structures, objects and changes in the runtime such that it seems as if the script executed as a Java program in the same runtime.

By a language system we are targeting the same runtime, the same libraries via two languages. One for rapid prototyping and one for actual type checked, efficiently compiled prototyping. This is close to the .NET architecture except that instead of having "the one" runtime for all possible languages in the world, you have one runtime for each native language with a scripting dialect also compiled in the same runtime. Having "the one" runtime causes languages to be forced out of their natural being into a model more suitable to the runtime. Thus, if .NET has a predominantly object oriented kind of a runtime, Haskell or Lisp will look kind of odd on it.

Another compelling feature of scripting languages is that they are embed-able in applications. Thus, the native program itself can convert a script string supplied, to meaningful operations on its own data structures. BeanShell is essentially aimed at this. Such language implementations could be interpreted. However, it is again possible and desirable to be able to actually compile them on the fly and embed them in the existing language runtime. Such an API for executing scripts could actually be derived from the scripting dialect implementation itself as discussed in the previous paragraph.

And now some rant ;-). I have been looking at this language called Objective C lately. It seems to be a natively compiled version of a language like Java. Apart from that it is fully and efficiently interoperable with C (this is a big plus!) and has a powerful runtime. This it is an excellent candidate for being the native language part of a scripting dialect. The scripting dialect could be used for rapid prototyping without alienating a lot from the base language and at the same time contributing to a common pool of libraries. The scripting dialect would basically consist of the scripting language definition, and two implementations of it; one for compiling these to generate native code for the same runtime, and another providing an interpreting API which would allow us to embed scripts into applications. The interpreting API could as well be a Just-In-Time compiler, reusing the effort spent in making the native compiler for the dialect. Has anybody done this for Objective-C? (I have heard about a python implementation in python from one of my friends... we now know a use for that. But again, I won't choose python as a native language for a good language system.)

About the Author:
Ritesh Kumar is a graduate student in the Department of Computer Science, University of North Carolina at Chapel Hill. Operating Systems, Systems design and Development Platforms are things that interest him the most. He can be reached at ritesh at cs dot unc dot edu.

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
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