This document focuses on the langages we are using to develop OSDL's libraries and games. We try to explain our choices and give some pointers for newcomers to learn these languages.
For the moment, three main languages are used, and at least one more is still to come:
We will need at mid-term a powerful scripting tool (see why a scripting language) whose language has not be chosen yet. This subsection shows the study in progress so that we take the best-fitted interpreter.
C++ has several advantages over other languages:
Scripted languages are interpreted and not compiled: the translation of source code into processor instructions is delayed till (at least the first time) the code is executed. It has an impact on the properties fulfilled by the compiler, which is called in this case interpreter, and these properties elect scripting languages for some specific uses, and disqualify them for others.
In our case, game programming, an issue is that the compilation-based developing process requires huge amounts of time and very specialized know-how. It prevents many people from contributing to the code, and it leads to tremendous delays. What we would like is to open some specific areas of development to a not-too-technical population. This area is behaviour and events implementation, and AI (Artificial Intelligence), and these tools are scripting languages.
Learning these languages is easier and faster than doing so for compiled ones, not to mention C++; it is therefore a convenient way of sharing the workload and letting wide open the development to more people. However, one has to make sure that the main language (C++) gets well interfaced with the scripting one. The main solution for that is to embed the underlying interpreter into the C++ application, so that data structures can be shared by both worlds. In this case, the two languages can efficiently cooperate and work on the same data, and a computation can be made by either of the two, depending on what is more appropriate in the context.
In all cases, embedding an interpreter requires a kind of bidirectional translation of the objects that are to be shared, so that they remain usable by both. It is the dullest task, since painful measures are to be taken. For example, when the memory management is different (C++ relies on the developers to ensure that object life cycle is correctly handled, while interpreters like Python use reference-counting mechanisms, namely a garbage collector, so that the user has no concern about deallocation of objects), some rather low-level tricks must be used not to falsify the reference management. Hopefully, some helpers are available to ease translations of an object from a world to another. Thanks to them, the balance still tilts on the side of this embedded use.
Beyond this role, scripting tools have a second role to play in our project: allowing fast, flexible and simple development, as stated in the following subsection about Bourne shell and Bash.
Bash is a shell, a kind of lightweight interpreter which is oftenly used on UNIX platforms to directly type the user's commands and, what interests us much, to write small scripts. Shells are widely spread on most platforms, they are therefore tools we can rely on to be already available almost everywhere. To that extent, they are useful for installation procedures, for instance. Bash is a shell, and perhaps the most frequently available one, since it has been chosen by numerous operating systems to be the one available by default.
Bash is a specialization of the Bourne shell (sh), which is available on more platforms. Knowing that, finally, as bash offers little more features than sh, we chose to switch to sh.
Bash is far too elementary a language to develop a true application. Besides, it cannot be embedded within a C++ application. Bash is useful only for small installation or configuration scripts, and it is what we will do with it.
We currently think at two famous object-oriented scripting languages to be embedded in our C++ application, and at another one:
Python is an interpreted, interactive, object-oriented programming language, and its implementation is highly portable (check their own Python overview).
We have not yet decided whether we will use Python, LUA, Erlang, or no interpreter at all. To choose seriously, we should study them a little bit more in depth, and we should even try them on samples cases, to try to figure out which of the two corresponds the best with our goals.
If you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!