Ever since Unix became the role model for operating systems, C has been the “base” language. In desktop operating systems like Windows and Linux the platform API is expressed as C function calls, and the ABI (the binary calling conventions) for linking code from different compilation units and binary distribution units is also expressed in terms of the code that a C compiler would generate. A C compiler is the first thing you need to get the platform going, and C is a language that allows arbitrary applications to be developed and run on the platform. The semantics of dynamically loadable and shared objects are expressed in C, not C++, as the C++ ABI is too variable.

This ubiquitousness of C has also proven to  be a key enabler for higher-level languages. C is the language of choice to implement the basic virtual machines used by languages and programming systems like Perl, Python, Erlang, and Java. C (or C++) is also used as the target language of many modeling tools with code generation, such as MatLab/Simulink, Rational Rose, Rhapsody, and Labview. A single generator of C code can be reused to target many platforms. Sometimes C++ is the generated language (in particular for UML-based object-oriented tools), but C++ essentially falls back on the ubiquitousness of C to be able to call platform APIs and connect to other tools.

That is the state of things as we know them today. What seems to be happening is that this is slowly being deprecated… platforms are coming out where user code might not be possible to write in C at all, or where C programs cannot access the real platform API. For these platforms, it is quite difficult  port in an existing C/C++ portable program.

The first example is Google’s mobile phone operating system Android,where  Java was the only supported language at launch. Google have since made it possible to use C and C++ for some parts of an application, but it does not seem to be a full platform API allowing a whole program to be written only in C or C++:

“The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity,” the documentation says. “Typical good candidates for the NDK are self-contained, CPU-intensive operations that don’t allocate much memory, such as signal processing, physics simulation, and so on.”

To port an application written in C/C++ such as Firefox to the Android platform, the app has to be modified to work as a backend to the Java interface.  ArsTechnica has a write-up on how Firefox was brought to Android through just such a modification. Note that this does mean that ports are not as straight-forward as they would be to other platforms with a directly accesible C API. Interestingly, the Android approach essentially inverts the traditional relationship between C and other languages, where it was common to have a C adapter layer around other languages (like Java) in order to access the platform.

Note that the NDK quote does not mention language run-times. One of my favorite languages, Python, has had to be completely reimplented to run on Android. Either using a “Jython” approach of compiling Python to Java byte codes, or using the Android Scripting Environment.

Other languages that you would ordinarily just port using a simple recompile of the its C code base are not helped by this at all. One interesting example is the Erlang runtime, which is basis for CouchDB. According to an interview on FLOSS weekly show 99, about Ubuntu One, this fact prevents Ubuntu One from synching data from your desktop to your phone.  This demonstrates that the assumption that you can run a C program on “any Unix-like system” is no longer true for a large numbers of smartphones… and that is already affecting how you have to develop products.

Microsoft is also moving in the “no C for you” direction with Windows Mobile 7, where C# is the default language. This also prevents easy reuse of existing C programs on smartphones. Ars Technica notes how this killed Firefox on Microsoft-based mobiles.

Finally, we have Apples downright weird approach to languages and programming. Their recent banning of anything except Objective C and their own compilers for iPhones (and iPods and iPads) is downright bizarre. They explicitly forbid code-generating tools to be used with their platform, as well as kicking out any alternative language runtimes (which is a move aimed at Adobe Flash that also hits Erlang, Python, et al.). This might make some sense from a security perspective, as it prevents programs from loading executable code at run-time on the phone… but it also makes for a much more restricted set of programming tools.

The only mobile platform that seems honest to old traditions is really Nokia’s Maemo. And Symbian. Suddenly, what used to be considered “closed” platforms have become the most open and most desktop-like of all the mobile operating systems. Really, that is a very important reason to get a Nokia N900 rather than an Android or Apple device.

I think this points to a somewhat more complicated future, where mobile applications will cannot be cross-platform, as you have to use Android-Java, Windows-C#, iPhone-ObjC, and Maemo-C/C++/anything to code. It could also point to a move even in the desktop and server space away from C and to more sandboxed, controlled, and not-as-common programming platforms. That would be really bad from a programmer productivity and language innovation perspective, as so much of the innovations today are actually based on the ubiquitousness of C and the use of C as a good implementation language and code-generation target language.

Updates and clarifications

Given the comments below, it seems that I need to make some things clearer…

First, the iPhone. It is really a special case, in that you do have C/objective-C access to the API. So in principle, you could port any C program including language virtual machines to the iPhone. Firefox, for example, would work. However, Apple for commercial (and maybe security) reasons does not allow programs that implement virtual machines to be distributed across their controlled application store. That you can implement a VM there does not really help you, as it is the first openly programmable platform that I have seen where a control body actually forbids certain classes of programs. The Apple approach is apparently even more idiotic than I first believed.  According to some more reports I read and heard, they do not enforce a technical limitation on the final program (such as running in a JVM or .net VM), but rather require all software to be originally and directly written in C, C#, or C++.  All just a swipe at Adobe and flash… so even Flash compiled to native code is disallowed.  And with it goes all other higher-level languages.

Second, on security. I do think that running programs on top of a VM like done with Java and .net does have security benefits. It gives you a level of indirection which can be used to check what applications does. Obviously not perfect since there will always be bugs and mistakes, but still it is a better architecture than raw access to the underlying machine. The  iPhone controlled mode of distribution could also be beneficial here. The SecurityNow podcast episode 245 discusses this topic.

Third, on appropriate programming languages for different tasks. I totally agree with some comments that C is not a very nice language for GUI programming. No doubt about that. However, that was not really the point I was trying to make. I want to use higher level languages! But not having C available might make that harder and with limited choice… leading up to point four.

Fourth, my core point. Having platform-level access in C is a basic technology used today to implement the higher-level environments. Languages like Python, Perl, Erlang, Lua, and even the basic Java and .net virtual machines, all depend on having C available to bootstrap the process of getting the core virtual machine going. If we take this away, we limit choice in language and might stifle innovation, as well as the attractiveness of cross-platform environments.

Fifth, I agree with the comments C is definitely not going anywhere in terms of being used to develop operating systems and embedded systems (that’s where I spend most of my time, by the way). My observation is about what is happening to user-level programming for certain systems, not the systems programming which is intentionally made separate from user-level programming.

Another Update:

The Inquirer just pointed out that Apple is explicitly forbidding interpreters to run on their phones, unless it is an interpreter they created or one explicitly allowed. That’s making the above very clear, Apple is consciously denying iPhone users all modern programming languages. And that’s just to make sure Adobe can’t weasel Flash in there. Politics sometimes make no sense at all. The Inq quote is worth quoting:

Famously, when Apple released its iPhone SDK in spring of 2008, the end user licensing agreement barred applications from downloading and running any interpreted code. “No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s),” it said.