Slashdot Mirror
C Alive and Well Thanks to Portable.NET
rhysweatherley writes "So C is dead
in a world dominated by bytecode languages, is it? Well, not really.
Portable.NET
0.6.4 now has a fairly good C compiler that can compile C to IL bytecode,
to run on top of .NET runtimes. We need some assistance from the community to port glibc in the coming months, but it is coming along fast. The real
question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C? The death of C has been greatly exaggerated. It will adapt - it always has."
"Can I get them to compile asm to java bytecode next?"
Not as funny as you think. It would be a truly awesome program that can do that. Why? take MS office, disassemble make it java byte code then run it on the platform and OS of your choice.
dont see anything like that happening for a while, but it certainly is not funny.
The war with islam is a war on the beast
The war on terror is a war for peace
When you hear someone declare "X is dead" it usually means they have a vested interest in X actually dying, and wish to further that belief. Either that or it's more like a mafia situation where a statement like "X is dead" is more of a prediction with a strong likelihood - it all depends on the power of the speaker.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Flamebait.
Remember, a language does not cause overflows - careless and stupid programmers do.
C is built for low-level interface, and its best suited for that purpose. Its lean and mean, and thats how its meant to be.
If you want complex exception handling and all that, you are probably using the wrong language for the task.
Blame the people who used C for the wrong task, not the language.
Vote for a Man, Vote for Bush!
Not a liberatarian flipflop hippie.
Claiming C is dead is plainly stupid. Languages are tools, not religions or whatever. Languages have their weaknesses and their strengths.
Fortran is extremely good for producing high performance number crunching code (it forbids array overlapping, and thus several assumptions can be made by the compiler). C is very low level and I would hardly chose another language when writing an operating system, it is also a fairly general purpose language, good for many things. If I am writing a GUI-app I would surely pick an object oriented language such as C++, Java or Objective-C. If I write a 3d engine, I'd like performance and an object oriented approach and I would chose either C (combined with self discipline) or C++.
The portability of Java and other byte code languages is surely appealing, but they usually produce a terrible user experience since the applications produced tend to have a user interface compliant with the developer's OS (mixed with the language's own HI guidelines). A Java app written by a Windows developer would probably look like a Windows app, even on a Mac, and the other way around. Consistency in user interface is very important I think, so my hope is that people write code according to the MVC principle, and thus ease porting of the application to other platforms. Just to note, I'm not condemning Java, it is a very useful language if you want an internal application that is to be deployed on different systems. Say that the graphics departement (using Macs) and the economics departement (using Windows) both need access to some internal database or application, then clearly Java is the way to go.
Anyway, select your language after the task at hand and write code with discipline!
"Civis Europaeus sum!"
The closest thing to that besides C is C++.
For general purpose programmming, C++ is often overlooked because it suffers from the same problem as C in this scenario, which is that there isn't really much in the standard library to draw from. C#, Java, Perl, Python, etc, all have lots of "foundation" underneath which allow you to build applications quickly.
However, this is not so much an issue of language as it is of API, and C++ has the language features necessary to build a good API. All that is needed is a good library then, such as the Qt C++ library. With Qt, you get nearly the same foundational API as Java, but with natively compiled code. C++ may not be the end-all be-all of languages (no language can claim this), but it is much more capable than many people think. If you wouldn't touch C/C++ with a 10 foot pole, you haven't tried Qt. You can have your cake (large, well constructed API) and eat it too (native code).
I have been doing Windows development for quite some time now. Both low-level and applications(these days).
.Net C compiler. If you are writing applications its better to use Java or C# anyday. C code does become unmanageable(pun intented) as the project size increases. You need all of encapsulation and inheritance to avoid nightmares of one huge gorilla staring at you!
.Net. But not for anything big.
C will not die becoz,
Most of the real high performance stuff is still written in C. Take Windows drivers for example. The only other option would be C++, but then when it gets down to that level you try to squeeze out every bit of performance. What I have noticed it that when you look at the complexity of writing a Windows device driver, the relative complexity of C versus C++ becomes a non-issue in most cases.
You cant write OS/drivers in bytecodes.
But:
There is no point in a
Maybe i exagerated when i said no point. Maybe for small projects, components that need to interoperate with the rest of
Life is just a conviction.
C is a procedural language. .NET is an OO platform. Really using .NET in a C program requires a lot of pointerarithmetic, which will make the C source not that readable.
.NET have to adapt the OO paradigm set for .NET in one way or the other, OR it requires serious compiler efforts (Eiffel) or just plain slow code (creation of objects behind the scenes and then call the method of choice). Finding static methods which do the same as the methods in stdlib and stdio is doable and will work, the real pain begins when a lookalike method of a stdlib or stdio routine is not static in .net, so a whole object has to be created.
.NET language like VB.NET or C#. How is the C program presented to C#? As 1 class with a very big pile of methods?
All languages on
That will not always work in all cases.
And what about interlanguage operability? An assembly in IL can be referenced from any
Never underestimate the relief of true separation of Religion and State.
C is going strong on Macintosh also. Cocoa programmers use mainly Objective-C which is fully backwards-compatible to C. You get the best of both worlds there. You can use C for the parts of your program where you really need the speed of C and can you use Objective-C where the advantages of object-oriented design best suit your program. Programmers who use the Carbon libraries instead of the Cocoa libraries also mainly program in C or C++.
There are many other languages available for Mac OS X but I would say that C, C++, and Objective-C are by far the most used. Since C++ and Objective-C are largely supersets of C, I would say that C is doing just fine under Mac OS X!
Sapere aude!
C is a brilliant language. It's beautiful and elegant. I don't need validation from any other entity to legitimize the *world's most successful computer language* that most of the major apps on this planet have been written in.
This whole story is a big troll, and if you're not a serious programmer, you wouldn't know it.
Boo hoo... built-in string boundary checking in newer languages. If anything, C is the catalyst for a plethora of invaluable programming habits that today's programmers seem to take for granted.
There is Ada95 which should come pretty close to your requirements, its pretty much like C, just with a whole lot safety added.
But you are right most of the new languages really don't touch the areas where C is successfully today. I think one of the major problems, at least in the Unix world, is that pretty much every library is written in C, so if another language should take over, you would have either to rewrite all libraries out there or at least create bindings to your new language and since that is a major overtaking it won't happen anytime soon.
The problem is in trying to make use of C++'s more advanced features, such as templates and classes, from some other language. Many C++ libraries depend upon the use of these features to function correctly. Mapping a C++ class heirarchy to some other language is almost sure to require a large amount of work. While I agree that a C binding can be created for a C++ library, this may not be a trivial task.
Consider, for example, trying to crate a C binding for STL vectors. Since C does not support templates, the work will not be easy. One option would be to create some kind of C preprocessor that could add generics to C; but this is exactly how C++ started in the first place (as a preprocessor). Another option is to create a pure C interface, then to implement that interface using vectors.
The problem is that there is a huge semaintic difference between C++ and C. Most languages include some sort of C interface, since C is low-level and an easy target for interoperability. Few languages come with support for interacting with C++. For interoperability, C's semantics are simple: just functions and data structures. Calling C functions from some other language usually boils down to just a wrapper for the function, along with appropriate marshalling code to convert data types. On the other hand, C++'s model of OOP is a one-of-a-kind. Higher level languages simply do not share C++'s view of OOP. While there are definitely similarities that are shared among most object-oriented languages, the differences are so wide as to make a general interface to C++ impossible.