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.

But note that the application IS written in C++ still: that is the only choice on the xbox where the project started, by design by Microsoft. However, you can use my favorite scripting language Python to script and skin the application.

The interesting material in the article is the background on WHY he thinks that this is the case. He points to the immense popularity and rise of scripting in much of computing land. In the past ten years, it is clear to him (and I would agree with this too mostly) that languages like Perl, PHP, Awk, Ruby, JavaScript, and Python have eclipse Java and C++ as the most interesting and important programming languages for many practical tasks. Especially for web applications, where Java seems to have a presence but noone would dream of using something as clunky and impractical as C.

What can this teach us for the purpose of simulation and the creation of models of computer system hardware for the purpose of simulation? Maybe a fair bit…

The reason that scripting languages have gotten so popular is primarily that they let you get the job done faster. In web land, this is due to a few important factors listed or hinted at in the article:

• The overall code tends to be shorter and more to the point
• A tendency to make any value into a string when needed (excellent debugging aid)
• Dynamic typing, variables that just appear when needed
• Automatic memory management
• Ease of handling strings
• Most tasks are pretty short
• Performance of computation does not matter very much when processors are as fast as they are today and a single disk or network access operations is likely to dominate programming time

What the article continues with a discussion that we need to focus on programming language pragmatics rather than syntax or semantics. How practical is the language for the everyday tasks of a programmer? And it seems that simple darwinian evolution has propelled scripting-style languages to the top of heap here. Purity and elegance and deep semantical properties are obviously less important than getting the job done in the shortest time possible.

What can this teach us modeling folks?

• A key takeaway is the focus on short code. Code has to be short and focused to be quick and easy to write. You should not need to consult several header files and lots of documentation to understand and formulate your code, which is an ill that keeps hitting C and C++ programs.
• Memory management has nothing to do in a productive programming environment.
• Basic types have to be appropriate to the task at hand.
• Syntax has to be concise and powerful.
• Dynamic typing is much faster to code with than static typing and variable declarations.
• An interactive “try it out” environment is preferable to long compile/link/test cycles.

Obviously, some of these do not translate well into hardware modeling. Hardware entities tend to have very-well-defined types by nature. If I have a 16-bit register containing a 13-bit counter and three status bits, I cannot very well let that counter be a dynamic variable that can take on any numeric value. Or the atom “foo”. It kind of has to be restricted in semantics to how the hardware would behave… it is not just a “value” to be manipulated quite abstractly. Which means that what you probably rather need are types well-suited for the task at hand.

It is also nice if variables can just pop into existence when needed, with the least amount of declaration possible. Another C-family performance killer is the annoying need to declare a function before calling it. That made sense in linearly scanning compilers back in the 1970s, but today, just let the compiler take the entire program into account and find the function. It is not that hard, especially not for the quite small and isolated context that a virtual platform device model is (few device models are more than a few thousand lines of code in my experience).

The interactive nature of scripting is also interesting. The ability to just write new code directly into a running system without an explicit compile usually rests on a virtual-machine approach and does have some cost in terms of performance. And unlike webservers, virtual platforms need all the raw CPU performance they can get! However, it make excellent sense to use an interactive environment to prototype and test things, and then move the resulting code to a harder compile stage.

Right now, we really do not have such a tool at hand. Virtutech DML is in my opinion the most promising step along this road, but it is not really “perl for modeling” at this time. SystemC has too many C++ roots to really behave well in this respect… you get all the drawbacks of explicit memory management, rampant headerfiles, and statically declared types. It might be good to compile, but it sure is an absolute pain to write.

And if we want virtual platforms to really fly, it is not so much “all about the models”, but really “all about model programming” — since there is a huge volume of models that need to written out there, and getting the time needed to write these models down is a primary concern. The total work invested in modeling any particular device is what we need to focus on, really.