On 2008-02-07, Bryan Richter <[EMAIL PROTECTED]> wrote: > Here's an honest question: what language do people think the next > operating system, the one that Ion users are most likely to write, will be > written in? C is the default choice, but I wouldn't be surprised if it was > something else...
C.. and then some. There's just no way around it: for any serious work you want C. Or maybe some other relatively simple language close to the hardware, with better safety... and tagged unions. (What was this one C derivative?) But the benefits of such an alternative (except for tagged unions) are not so great, because you only want to write relatively simple things in C/it. You don't want to write much abstractions in C. You do low level gruntwork of core libraries in C, provide a very simple API, and use whatever language you want with better abstractions and better safety (hence typically no dynamically-typed scripting languages, but rather e.g. Haskell), to access the services provided by the C core libraries. This is easy because the API is simple (instead of OO bloat). Non-performance critical libraries could also be written in other languages (such as Haskell), and they could provide a simple C API, but conflicting runtimes present a problem. Many languages (including Haskell, java, etc.) want to be operating systems themselves these days. Instead of using the operating system's namespace to locate their libraries, they want to impose their own module and package namespaces and hierarchies. Instead of exposing the operating system's libraries and services, and letting the program author choose either some real platform or a compatibility layer (platform), they want you to use their own compatibility layer. Megalomania pure and simple. And in exchange cross-language compatibility is reduced. For that you either you either have to write for the "C runtime" (i.e. the OS), or you need something like CLR (common language runtime). I think the C option could promote better API practises instead of OO-bloat. You _do_ often want to write higher-level APIs suited to the practises and mechanisms of any particular language, instead of enforcing an uniform one. Those exposing a simple easy wrappable API not dependent on the idiosyncracies of any particular language or design methodology (such as OO-bloat), should work best. -- Tuomo
