As part of my regular attempts to improve my computer culture, I have recently ended up taking a look at the Ada programming language. The main goal there was to understand why its proponents were claiming that it was more suitable than others for developing software which have to be extremely reliable such as that of trains and airplanes. In the process, and in particular while looking at this paper from John Barnes which tries to summarize what this language is good at, I couldn’t help but notice that the language could be an interesting choice for OSdeving. To be more precise, here’s my current view of the pros and cons of using Ada for that purpose.
- OS code is notoriously hard to debug, so any help from the programming language to avoid classical programming errors is welcome. Ada tries to do this in a number of ways, such as by having true type safety, providing a “named notation” for easily managing functions with lots of optional parameters and structures with lots of fields, and enforcing appropriate caution in the handling of pointers and array types.
- The language also attempts to help debugging more subtle logic errors, by allowing a developer to clearly specify things such as code preconditions and postconditions, limits of integral types and arrays, or restrictions on the ways a piece of code can be used (e.g. “limited” objects that can’t be copied).
- In spite of this focus on programmer safety, the language also targets embedded and real-time programming as a core use case, meaning that it provides quite a lot of control on data representations and storage, along with a relatively predictable performance, without having to resort to nonstandard and ill-readable compiler pragmas.
- A lot of care has been taken to make the language communicate well with code written in other languages, such as Assembly, Fortran, C, C++, Python, Java and .Net languages, even if it does often require use of toolchain-specific mechanisms.
- While too many programming languages require some code to be directly written in headers, or do away with headers altogether, violating the principle of implementation hiding, Ada strives to provide a very good control on code visibility, allowing for optimal separation between a code’s interface (called “specification” in Ada parlance) and its implementation. When some implementation details do have to be exposed for technical reasons, such as allowing for separate compilation, it is possible to make them private so that external code cannot directly access them.
- Multitasking and concurrency are treated as a first-class concern, and handled with an amount of care that is rarely seen in languages that are also suitable for low level programming.
- Using a relatively obscure programming language means depriving oneself from the assistance of most system developers and written resources, which tend to use other programming languages like C or C++
- Although the language seems to lend itself pretty well to bare-metal development, implementation support for this use case may vary. The OSdev Ada Bare bones tutorial, as an example, shows the fair level of complexity that is involved when building a proper cross-compiling OS development toolchain for Ada based on the popular GNAT environment.
- There might be other issues which I do not know yet as an Ada newbie, and I’d like to try the language out on a few simple projects to see how much it is actually worth in everyday use. Just to end this with a lame pun, the few bits which I have read about Ada so far certainly SPARKed some interest in me…