Low-Level Libraries and High-Level Languages

If you want to write a library that could relatively easily be used in embedded systems (say Xbox 360 / PS3) as well as being generally portable (Windows, Linux, Mac OS), then you end up in a bit of a bind. You can use C and be on the safe side, but for some types of programming C is rather cumbersome (see for example the Io language). You can use C++ (or one of its subsets), but now any client of the library has to understand the C++ ABI (which AFAIK only C++ does). Another option is to use whichever language is best suited to solving the problem you’re addressing in the library, but that usually imposes constraints on what can use or bridge to the library (e.g. if I were to write a library in Python, how do I use that from an application written in C++?).

Now, if whatever you’re coding is a low-level component, then this restriction becomes even more imposing because many higher-level pieces are now depending on and interacting with the library itself.
If you restrict yourself to running on Windows only (as that is the only platform where you can realistically rely on the CLR run-time being available) and don’t mind its overhead, then using .NET and the CLR will solve this problem for you nicely. For running on anything else, you’re pretty much screwed… 🙁

Leave a Reply

Your email address will not be published.