In addition to strong personal preferences, there are many practical reasons to choose one language over another. Speed of execution, speed of coding, legacy code, portability, programmer familiarity with languages, availability of libraries, and appropriateness to application domain are all important factors in deciding which language to use.
For library developers such as ourselves, the huge number of available scripting languages is a real concern. We are developing Pad++ , a general-purpose substrate for supporting zoomable graphical interfaces. While our library is written in C++, we want to provide a scripting language interface so applications can be written at a higher level, and prototyped more easily. Until recently, we supported only Tcl/Tk  which was adequate, but limited the number of potential users of our system.
We now continue to support Tcl/Tk, but in addition, we provide a generic mechanism to add support for any other scripting language. We have used this mechanism to add support for Scheme (the ELK distribution ) and Perl . Our approach provides these features:
There have been other approaches to the multiple language problem. STk provides a Scheme interface to Tk, but eliminates access to Tcl . Guile provides a base language which is intended to provide the ability to write interpreters for any other scripting language . This approach is promising, but is still under development and has the potential problem that each scripting language will be slower than the original since it will be interpreted in Guile rather than in its original implementation. Despite the quest for a universal language, it is unlikely that a single language will ever satisy everyones needs, and the issue of giving access to a library through as many languages as possible remains.
In addition, languages that support a top-level interpreter also need to provide:
To access our Pad++ library, each language must also specify two special functions.
Our implementation of access to multiple scripting languages in C++ is based on two classes, Pad_Language and Pad_Script. An instance of Pad_Language is created for each new scripting language. It contains pointers to six C++ callbacks that implement the functions described above. Then, every script, whether it is an event binding, or a command typed in the interpreter is instantiated as a Pad_Script with a pointer to the language the script is written in. The Pad_Script contains an Eval() method which evaluates the script in the appropriate language.
The only other special code deals with the top-level interpreter. An interpreter typically prints a prompt, receives input, and when the input forms a complete command, the command is evaluated. Finally, this cycle is repeated. Normally, these four steps are hard-coded for a specific language. With our approach, we simply call the appropriate call-back function for the current language.
The following sequence shows a very short usage of Pad++ moving back and forth between Tcl and Scheme:
% puts "hello"
% .pad settoplevel scheme
> (+ 2 2)
> (set! foo 42)
> (settoplevel `tcl)
% .pad scheme get foo
One difficulty we had is that not all scripting languages provide a well-defined and bug-free mechanism for converting internal types to strings. Since this is a very useful facility for the now common practice of embedding scripting languages in external programs, language designers would be well-advised to provide, test, and document string conversion facilities.
This work is supported in part by ARPA contract #N66001-94-C-6039.
 Benjamin B. Bederson, James D. Hollan, Ken Perlin, Jonathan Meyer, David Bacon, George Furnas. A Zoomable Graphical Sketchpad For Exploring Alternate Interface Physics, Journal of Visual Languages and Computing July, 1996, pp. 3-31.
 Benjamin B. Bederson and James D. Hollan, Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics, Proceedings of ACM Symposium on User Interface Software and Technology (UIST'94), 17-26.
 Benjamin B. Bederson, Larry Stead, and James D. Hollan, Pad++: Advances in Multiscale Interfaces, Proceedings of ACM SIGCHI Conference (CHI'94), 315-316.
 John Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, 1994.
 ELK Scheme: http://www-rn.informatik.uni-bremen.de/software/elk/elk.html
 Perl: http://www.perl.com/perl
 STk: http://kaolin.unice.fr/html/STk.html
 Java: http://www.javasoft.com