I think the comments and the article confuse two things.
(1) C is in danger of actually dying, as in: going away (2) C is in danger of losing some share of application development.
I think #1 is just not true. Almost every close-to-metal programming uses C. Yes, it is true that not many developers do this close-to-metal programming (which would include kernel development, driver development and embedded development), however, this close-to-metal development is very, very important, because it is the foundation to all application development. And at the moment, C and C++ are the foundation to the close-to-metal programming. Thus, C and C++ are pretty much the foundation of application development. Maybe hidden, but certainly alive and important.
On the other hand, C has already lost a lot of shares in application development, if you define application as some custom buissness application, maybe web-based, maybe gui-based and I certainly agree that C will lose more shares in this area. And I have to say, this is a good thing. The focus for C is just different from the focus one needs for such application development, because for higher level application development, maintainability and extensibility are more important than using every cpu cycle and every memory byte to the most effect.
tl;dr: In my opinion, C is a small important layer in the stack and not in danger in the area C was made for.
Objective-C is C plus brackets and a recv message function. Everything else is built up on that. You can very easily use c libraries in iPhone / iPad development.
Maybe this is true on android, but iPhone is a great platform for c programmers.
so I can just run my regular code in Obj-C and it should work with minimal boiler plate? I guess the barrier to iphone dev isn't as high as I was imagining.
Objective-C is much closer to the 'just a pre-processor on top of C' idea than C++ is at this point. ANSI C is still valid, though to hook into Apple's CocoaTouch APIs I believe that you will be forced to write ObjC.
I think so. I believe that it just converts all of the ObjC constructs into valid C. The ObjC constructs are different enough from C (being SmallTalk-inspired) that I don't think it's an issue. Take this with a grain of salt though, as I have minimal ObjC experience.
I think that Apple should find a way to certify languages that expose all of the iPhoneOS APIs without an excessive penalty for runtime footprint. So long as all of the APIs are exposed in an easily used fashion, then it just becomes another way to code on the iPhone and Apple remains in control.
This would enable languages/environments like Scheme and Mono to operate on the iPhone.
I think Apple would only be happy if those environments exposed all future APIs on the day they are released, which is a very difficult promise to make.
Another article that sees only the high-level side of software development and comes to wrong conclusions.
C is going to be there universally until the cpu hardware changes dramatically, such that it maps one to one to some other language. That's where the universality is coming from. C maps directly to what cpu understands.
Towards the latter portion of the article he talks about cross-platform development. Though I agree that this would somehow get reduced, I can't help but feel that this would also have some good points.
The write-once, run-anywhere ideals have only applicationst hat work beautifully on the original platform they were developed on, and poorly on others (eclipse on mac, skype (before they re-wrote it for mac), itunes on windows, etc.)
Without further analysis or background, just looking at the figures and the ordering it would appear to me that that table is incorrect in several ways at least.
Pascal usage greater than actionscript? Delphi on the rise and javascript dropping? Python dropping? Go already larger than actionscript?
how many people do you know who write kernel (or other low-level OS code)? i think there are now more and more devs writing apps than systems code, which means a rise in the use of higher-level languages (just my wild speculation)
I don't see C dying until we have computers with radically different architectures. C is too good a fit for current computers and there is too much installed base and too much cost for conversion for things to be switched over until it is really necessary.
The premise is that because Windows Mobile does not allow, and Android makes it very difficult to run C code, that therefore "C might be on a decline as the universal programming language." (He incorrectly states that the iPhone "only" allows Objective-C). That's not very convincing.
Until Apple, Microsoft, Google and others start writing their operating systems in Java/C# instead of C, I wouldn't worry.
Writing the OS in C doesn't mean that the main apis are in C. That's the point. I can't compile my favorite language on android and easily access the main android apis like I always could in the past.
He specifically mentioned the difficulty with things like erland, couchdb, and firefox.
> Until Apple, Microsoft, Google and others start writing their operating systems in Java/C# instead of C, I wouldn't worry.
Keep in mind the runtimes those languages require is written in some flavor of C. Even with Squeak, where the VM is written in a subset of Smalltalk, it's transformed into C and then compiled to run natively.
Having said that, I have, long, long ago, designed a stack-based architecture that would run something very close to Forth. Got me an A+.
Microsoft's plan was to build most of Longhorn on managed code. For what was publicly said, it became clear that plan didn't work out, they had to scrap most of what was written up to then and start from more or less scratch. Vista was released late as a result, Jim Alchin retired and the same codebase lived on to become Windows 7.
Lisp machines, I think, proved the concept that, if your CPU is clever enough, even the low-level code can retain a high-level of abstraction.
Sadly, I have none to play with. Someday I intend to correct that.
"The Technical Strategy Incubation team is looking for a senior software architect to lead development of the Kernel for a novel operating system. Because this is an incubation, the candidate must have a high tolerance for uncertainty. Experience in startups is a plus.
Our Kernel is a non-traditional design divided between a native C++ microKernel and additional managed C# operating system functionality which is injected into each independent hardware address space. The system uses lightweight isolation and capabilities as the basis for security, is built from the ground up for safe concurrency, and enforces unusual principles like "no unsafe shared memory." ..."
You can currently download Singularity, which works but isn't polished enough or Windows-compatible; Midori's rumored to be a project to adapt Singularity into something that could become a future version of the Windows product (though there are also other rumors).
(1) C is in danger of actually dying, as in: going away (2) C is in danger of losing some share of application development.
I think #1 is just not true. Almost every close-to-metal programming uses C. Yes, it is true that not many developers do this close-to-metal programming (which would include kernel development, driver development and embedded development), however, this close-to-metal development is very, very important, because it is the foundation to all application development. And at the moment, C and C++ are the foundation to the close-to-metal programming. Thus, C and C++ are pretty much the foundation of application development. Maybe hidden, but certainly alive and important.
On the other hand, C has already lost a lot of shares in application development, if you define application as some custom buissness application, maybe web-based, maybe gui-based and I certainly agree that C will lose more shares in this area. And I have to say, this is a good thing. The focus for C is just different from the focus one needs for such application development, because for higher level application development, maintainability and extensibility are more important than using every cpu cycle and every memory byte to the most effect.
tl;dr: In my opinion, C is a small important layer in the stack and not in danger in the area C was made for.