Some recent developments among development environments for mobile phones have made me consider the hereto unthinkable: that C might be on a decline as the universal programming language. Indeed, maybe there is even a chance that we will not have a universal low-level language in the future at all. What is happening is that the hitherto “given” role of C as the base language for a platform is being questioned. The reason appears to be security, which cannot be said to be a bad thing. However, a large-scale move away from C might hurt many of today’s higher-level languages and even model-based engineering.
So what is going on? For the past decade or two, and even longer back than that on Unix platforms, it has been a truth that a (well-written) C program can be made to run on any platform. All platforms have had C compilers available (even Windows), and C programs with a dash of platform-dependent code in file operations could be easily made portable. This has been used by common cross-platform application programs like Firefox, the Gimp, MySQL, and Wireshark, as well as by technical products like MatLab, the Diab and IAR C compilers (which I once worked on), and Simics (which I currently work on). It is a way of creating software that in my experience works very well. Especially since pretty much anything higher-level can be made to link with a basic C code base.
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.
I would say that C is mainly going away from layers higher up in the software stack. If you look at Android for example (http://android.git.kernel.org), you still have pretty much everything at the lower layers (bootloader, kernel, libc, JVM, as well as most of the system-level libraries) written in C. If you add C++ to that, you also get the browser as well.
However, for normal Android applications (at least newly written ones), I doubt if C is the best language anyway, so there I think it will be increasingly uncommon.
of course you are right in that the software stack is mostly in C/C++. But the key to me is that regular developers of applications are discouraged from or prevented from using plain C/C++ and the platform API. I agree that C is usually not the ideal language for a user-level app… but porting something already in C to a new platform should be allowed. Also, I think that allowing C is key to allowing higher-level languages which almost universally use C as their implementation language.
Oh, absolutely! I definitely agree that building C applications should be allowed (it’s even an area where I’ve done some work in the past :-)), but I don’t see it as much of a problem that it’s not part of the official platform APIs. After all, bindings for different languages tend to show up after a while anyway as long as it’s technically possible (look at GTK for example). It’s really just the other way compared to what you have with Maemo: instead of providing Java bindings to a C/C++-based API, you provide C/C++ bindings to a Java-based API on android.
For higher-level languages, it’s certainly a challenge. However, even there I’m not quite sure that it’s such a big problem. For Python, we have pypy, ironpython and jython as you mentioned, and I believe ruby and other languages are also possible to run on a JVM these days.
Anway, it provides for an interesting area to follow in the future, both platform-wise and language-wise!
Hi Jakob, all of this may create an opportunity for another provider like Canonical to bring Ubuntu to mobile devices. They started this way with the Netbook edition and recently hired a bunch of people to work on the ARM architecture.
Pingback: Tweets that mention Observations from Uppsala » C in Danger – and thus Higher-Level Languages (?) -- Topsy.com
> Finally, we have Apples downright weird approach to languages and programming. Their recent banning of anything except Objective C…
Not true. Apple explicitly allows C/C++ along with Objective-C. Objective-C, some would point out, is a superset of C, so obviously programs written in C are allowed on the iPhone.
Pingback: Tweets that mention Observations from Uppsala » C in Danger – and thus Higher-Level Languages (?) -- Topsy.com
Yes, but not C used to implement other languages so that you can download and run code without going via the AppStore. FLASH is a case in point…
I would say that you just need to build a CVM on those other platforms.
Every Objective C program on the iPhone and the Mac has a main(). It sets up the Objective C environment and the run loop… rather like XWindows. Objective-C is strongly based in C not only from a linguistic perspective, but also how in how its run time is implemented. You can find more details in my book about Cocoa Touch.
This trend has really been going on for a long time in practice, if not entirely in theory. Consider the following platforms:
– Mac/iPhone: You can write C, but you can’t bind to most of the APIs with ObjC, which is physically possible, but extremely awkward. Carbon has been deprecated for a while now.
– Android: Pretty much the same. You can call from C into Java code, but it’s a PITA.
– Windows: Platform and GUI APIs are still C ABIs, but you can’t use any of the .NET stuff easily from C.
– Web: Pretty much screwed, except for NaCl. But NaCl still has the same problem that accessing the browser’s “native” APIs is a giant PITA from C.
This seems to show up most commonly in GUI APIs, and I believe the reason is that GUIs are a PITA in C. Making these APIs easily C callable would just hamstring the building of the core GUI libraries (used Win32 HWNDs lately? kind of blows).
Pingback: Tweets that mention Observations from Uppsala » C in Danger – and thus Higher-Level Languages (?) -- Topsy.com
C and C++ are still king in embedded / operating system / interrupts / speed.
Objective-C is a strict superset of C, so it’s not right to say C isn’t allowed on the iPhone. Most of Apple’s libraries are Objective-C, but Apple actually allows C (by necessity, since every valid C program is also valid Objective-C), C++ and Javascript as well.
I’m not sure I would come to the same conclusion as you do from the current state of affairs.
Firstly, I don’t think there’s a really strong argument to be made that moving away from C provides added security to a system. The only cases where it’s particularly difficult to sandbox C is in really low-level embedded situations where you don’t have an MMU or protected memory. Google’s NaCl, though not yet extensively proven is a sandboxed C/C++ environment, and the C library on which it relies (Newlib) provides a fairly easy way to hook what would be system calls and redirect them however the environment provider wants.
I think it’s quite possible that, as some others have mentioned in the comments, that C is going away in the higher levels of the software stack, but companies have been trying to do this for quite some time. It may just be that they’re becoming more successful in recent years because computers are fast enough and software stacks are stable enough that details of the hardware implementation can now be ignored more successfully. Also, given that what many people are learning in school these days are higher level languages, it’s not surprising that companies are attempting to make their lives easier by providing higher level languages for development. This allows them to 1) minimize the API/runtime surface they have to maintain 2) claim that the tools and environment they provide allows for quick time-to-solution for applications 3) make it much easier to bring developers along when underlying hardware changes are made (by only allowing development through provided APIs and/or using VMs that are platform independent).
Given that the lower parts of the stack are still written in C, I doubt we’ll be getting rid of it any time soon. Heck, we’re not even ditching FORTRAN anytime soon (especially in HPC). I think what we’re seeing here is a gradual shift towards higher level development environments, which has been going on for quite some time. It may be that the average developer won’t have written anything in C in the near future, but, frankly, that may already be the case. It doesn’t change that it’s probably not going anywhere in the low-level portions of the stack, just like hand-optimized assembler still has its place.
I don’t think we’ll see C disappear until there are software stacks that cut it out entirely, and such environments start becoming quite popular. For that to happen, I think we’d need to see some significantly different underlying computer architectures. On this latter front, I think you’ll find that where new architectures and development paradigms are concerned, C is alive and well. Case in point: OpenCL. The development environment is essentially C99 with some changes to make it friendly to that type of hardware.
With all of the concerns about scaling large-scale applications online, I wonder if we’ll see a resurgence of web-apps written in C or even C++. I think OkCupid is currently one of the biggest examples of that. When you have Facebook inventing a PHP -> C++ compiler in HipHop, there’s gotta be something there. Also, where C is traditionally used really can’t go away anytime soon.
the big bad wolf is always around the corner.
c isn’t going anywhere, its not in danger.
(although the supposition does make a juicy headline)
in particular usage cases c doesn’t fit certain corporate development models, but much of corporate rationale is political rather than technical.
the fact still remains when everything falls down c is still “the hammer” of the computing community.
i don’t think its healthy to extrapolate the relevance of a language by examining a handful of non-mature target platforms.
its not a complicated future….its a future where programmers will have to be more committal about what platforms they choose to support.
i for one welcome less fence sitting.
Pingback: Tweets that mention Observations from Uppsala » C in Danger – and thus Higher-Level Languages (?) -- Topsy.com
Yes… but if you are not allowed to use C as an end-developer, you cannot yourself implement that host-independent VM. Leaving you at the mercy of the platform provider, which currently tends to me platform-specific languages in the mobile space.
As far Apple goes, Objective-C is a proper superset of C (unlike C++).
Updated the post to reflect some of the comments, please go back up and read the updates section.
> 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.
Nowadays, C can do it too. Search for “vx32”.
C will never die because it’s fast and speed is what programming is all about.
We are making high level C. Give it a try. http://www.lightningstormsoftware.com
@thisrod
While vx32 is interesting, it shoots totally in a different direction. My point is that it is hard to build a VM using anything but C, and that by outlawing C from user-level programming, porting VMs get harder. Note that the Apple case is different, they rather disallow higher-level languages just to block Adobe.
Aloha!
It seems Apple is at least somewhat reversing on its bizarre stance. The new terms of usage for Xcode contains the following wording:
“Unless otherwise approved by Apple in writing, 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). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.?”
Se more here: http://www.appleoutsider.com/2010/06/10/hello-lua/
The ban on how code has been written (esp code that writes code) is still sooo weird and must be incompatible with XCode itself. How should include files, macro expansion, buildbots be used without violating Apples rules?
@Joachim Strömbergson
I think this guy nailed it – it is all about the ads – iAds:
http://alarmingdevelopment.org/?p=380
At least now Apple has backed off of the programming languages a bit – as long as it still compiles statically: http://arstechnica.com/apple/news/2010/09/apple-relaxes-restrictions-on-ios-app-code-iad-analytics.ars