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."
...stop telling me things are DYING, maybe let me know when they're DEAD.
Isn't C++ widely portable while giving mast if not all of the features of C# (except for being interpreted)
C is still alive and kickin' in the NIX community I'd say. It seems it's really just Windows where other languages (C++, C#) seem to be taking over. Just because C isn't being used much in the Windows world doesn't mean it's dying ot is going to die anytime soon.
Buckethead
C?
Yeah, just kill it off already... I wanna go back to using Commodore 64 BASIC.
READY.
PRINT ""+-0
All the advanced language features of C with all the speed of an interpreted VM!
Can I get them to compile asm to java bytecode next?
C lives on; driven by an insatiable unreasoning swarming hunger. Until the day when the seventh seal is broken, the sun dies, and all the languages are at last bound to it's dark will. Then all of man, in the Doom of our time, will writhe in agnoy for a thousand years of darkness until the, strongly typed, Rapture casts the dark empire back into the pits of hell, and scatters the damned to the winds.
QUOTE: 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.
.NET API's are by no means 'pitiful in number', and they can be embraced, extended, and overridden as desired. C *can* adapt, but the point of a C# based desktop system or development platform is not solely to exclude C, but to bring the benefits of managed code to other system consumers. C could adapt, but not without a lot of overhead and fundamental changes that really is the point behind C#. I'm sure we'll be in a backwards-compatible, C-friendly world for a long time to come, but there's no reason to bash something new and different because it is new a different. That's just FUD.
Now what a spin. The
Be very, very careful what you put into that head, because you will never, ever get it out. -Thomas Cardinal Wolsey
FORTRAN and COBOL are still in wide use, even if they aren't as popular as they once were.
Mea navis aericumbens anguillis abundat
C has it's problems. You could complain about C all day, the problem is, it's the best thing we have right now. One of the problem with modern languages is, you can't write an operating system in them. One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code. Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable. The closest thing to that besides C is C++.
And its done by someone with a new technology to get people talking about it. Look at all the debates and forum chatter that got sparked off by intels "Bluetooth is dead". "C is dead", "CISC is dead"....
,"Apple is dead".
When technologies really do die, its when noone gives a damn about them, and so noone will be writing a story about it.
Linux is written in C, SDL is written in C, X (I think) is written in C. The gimp is written in C (along with GTK). Gaim is written in C. There are almost 13000 projects on sourceforge that are registered as being written in C.
C is neither bad nor dead (not that it doesn't have its problems). Whoever wrote this article and the previous one about it on slashdot is a moron.
You can mod your friends, you can mod your nose, but you can't mod your friend's nose.
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
Summary of argument to date (translated from geek-speak):
> Queens English is so dead.
> Yo, it's all about Ebonics.
> Dude, Southern Drawl is *soo* slow... Surfer speak is a way better language.
> Like, Valley Speak is, like, the best networking dialect to know!
> Well, if you want a job with a blue-chip company, go with Chicago Twang.
> I hear that they're porting the Queens English libraries to Chicago English, btw.
> See? Queens English is not dead...
Dialects, people... just dialects. Try to see things in the broader scheme of things. (punny, eh?).
It's just pining for the fjords.
http://cat.nyu.edu/~meyer/jasmin/
However, you should check News.Google.com frequently in case the world ended and no one told you.
When a language has to piggy back on another or come up with these weird combinations you know it is on it's way out. With that logic every language with a .NET version is dead. First of all their are plenty of projects that hanve ane will continue to be written in C and compiled into good old unmanaged binary executables that execute without any of this newfangled bytecode. Also the whole point of .NET and the JVM is compile once, run anywhere. Java and Foo# are just languages well suited for such tasts. Programmmers always find a way to use whatever weird language, library, or methodology with whahtever new technology.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
There are a huge number of applications that have very stringent time constraints, especially in real-time control. Other than coding in assembly, there isn't any other language out there that is as efficient (both size *and* speed count) as well optimized C code.
As an example, our lab works with humanoid robots that run in a 5ms control loop, which means that the next command (computation of inverse dynamics, etc.) has to be ready in that timeslice. If you want to do fancier stuff like machine learning and AI, you'll have to squeeze in many more operations into that tiny window. Sure, additional processors are a plus, but you still need very fast and memory efficient code.
"In mathematics, it's not enough to read the words -- you have to hear the music"
I know. I killed him. I ran him down in my PHP-mobile while drag racing with those Ruby punks on their friggin crotch rockets. At least C++ had the sense to step out of the way. I guess they were arguing about how their half-witted brother C# knocked up his half witted twin sister, Java, and produced some hideous premature birth thingy who they called Mono. I would have turned around and hit C++ had I not blown a module and had to stop. Those Ruby punks gave me the bird, but you wait and see. I got this new Zend nitrus which knock the socks of those badboys but I don't know how plug it in. Anyone got the number of a good mechanic?
This is not a turnip.
...is like saying too many busses will eliminate sports cars.
The C design paradigm (low level, varied environment, highly optimized, developer control) is intended to solve an entirely different class of problem than Business runtimes (higher level, standard interface, managed resource, developer handholding). The two aren't in competition much at all.
Nor do I think much about trying putting a racing-wheel on a bus either. We already have C# and "Managed C++", both which can look quite a bit like C, if you want them to. All you have to do is ignore that they're fundimentally different in the way they treat resources due to the underlying runtime or lack thereof. (Which is like equating a bus to a sports car, ignoring the size and speed issues.)
Saying C will die out is like saying that assembler will die out.
There will _ALWAYS_ be parts of an Operating System, hardware-oriented realtime or embedded app that _needs_ to be close to the metal. C/ASM is predictable, consistent, flexible and fine-grained in the things you can do with it. You certainly don't want a time critical interrupt handler routine that is supposed to be done in 5ms to suddenly decide that it needs to do some garbage collection or page in some hashing function to access an array of some sort.
Plus, C is great because it isn't assembly.
Even then, sometimes you just gotta write some ASM.
Sure, someone might make a "better" C that has similar goals (structured around ASM-style thinking rather than human-style thinking), but if they did it surely would be some incarnation of C. Compare traditional K&R C with the current features of GNU C (hooray for structure member tags!) or even the ANSI C99 specification.
Even though there has been no great change in the approach to programming itself (compare to LISP, haskell or Perl), C has nonetheless had continuous improvments along the way, from language and data structure standards to libraries, compilers, debugging tools, code profiling, and so on.
I find it hard to believe that we're going to have OS-level DMA transaction code written in Java or C#.
I once read in a visual basic for dummies manual (or was it Delphi?): "Trying to write an Operating System in Basic is like trying to fly to the moon in a hot air balloon".
At some point, you've _GOT_ to talk to the hardware.
- Paul
Or we can look at it like this: "Wouldn't it be better to have many different toolkits that allow string concatenation and tokenization than one standard library of string functions?"
Or maybe this: "Isn't it great that we have several different native APIs for threads, processes, and IPC depending on underlying platform, five different and incompatible implementations for cross-platform usage, and no way to easily switch between implementations after the project is underway?"
And next shall we talk about databases? Or maybe sound processing? Or regular expressions? Hmmm...
The thing that C zealots fail to recognize is the need for clean, standardized APIs (NOT implementations). If you write code that uses strncmp(...), aren't you glad that you don't have to worry if the C implementation is the BSD libc or glibc or MS Windows' C library? Don't you wish the same could be said for the user interface libraries -- for example being able to swap out the Qt or GTK+ implementations at compile or link time? Or the database libraries? (ODBC? Don't make me laugh.) But you can't because each implementation has its own interface even though a button is a button, a checkbox is a checkbox, a database connect is a database connect, a regexp is a regexp, etc.
This is what .NET gives; Not the mandated implementation, but much better it gives the recommended interface. If the C folks get it together and standardize more than just things like printf(...) and linked lists, you will get no end of gratitude from me and the gratitude of folks who are tired of reinventing the wheel and solving problems that were adequately solved twenty years ago. Unless that happens, you're gonna see more and more people moving to things like .NET and Java, warts and all.
POSIX was a good start, but it has stagnated and is showing its age.
- I don't need to go outside, my CRT tan'll do me just fine.
Please don't. Yes C++ as a language has compilers for many platforms which are pretty much compatible, but the degree of compatibility of these compilers don't mean much since the compatibility of an application is a totally different story. An application written in C++ will be using some kind of library, for DB access, for GUI, for network operations etc... Most of the times, these libraries are not cross platform. Or they have to be extended with platform spesific code. It has been discussed in /. many times, check it out yourself. Cross platform GUI, cross platform libraries, and there is almost always a catch in all the solutions. .NET i just don't believe MONO guys can keep up with it. C# 2.0 and longhorn will be a huge step forward for .NET technologies, and i don't thinkk MONO team can find resources to keep up with MS. .NET.
The story may change if you are writing C++ code that can stay in some kind of boundy, without using much library code, but unfortunately, i did not have that chance.
IMHO, java is really successfull in cross platform software development, without much work i can make java software work on another platform.
If C# had the same future, i'd be really glad, since i like it too, but as Microsoft works harder and harder on
Don't get me wrong, i loved the work they've done, but the result will be a platform inferior to java 1.5 and
So i'll be using C++ for platform spesific, high performance apps, C# for windows apps that require rapid development, and JAVA for cross platform. That's my 2 cents...
Of course you'd also have to disassembly every library MSOffice uses and every library those libraries use which includes the NT kernel. So by the time you're done, you'd be running Windows in a JVM just to run MS Office.
You know the old adage, "Use the right tool for the right job?" Well, use C when you need it. C is probably the most misused language I've ever seen. But of course, this is Slashdot, the land where opinions are forged and are never to change.
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.
... if I had an equivalent set of class libraries. Haven't actually seen one for C++, but Cocoa for Objective C is pretty good and there is an ObjC++ compiler.
The way I see it, the benefit of garbage collection is nearly canceled by the lack of stack variables and guaranteed destructor calls. I want to just declare a "Socket" variable in the middle of my function and have a guarantee that the socket will be closed when the block is existed in whatever way. finally or with just don't cut it. Say, I use 2 sockets, 1 file, a mutex and a temporary hash table entry at different points in a function. Imagine the mess of nested blocks, especially since Socket.close can actually throw an exception!
By contrast, memory management problems in C++ can be mitigated by destructors, reference counting and containers that automatically free members. Not ideal, but usually doesn't disfigure your code.
Now add other things missing from Java and/or C# - preprocessor, templates, multiple inheritence, operator overloading, unsigned types - and the new languages are really not that compeling for large projects that need heavy-duty, "dirty" features to manage complexity and can afford a regression suite that runs under Purify to fix memory corruption or leaks.
I know Java 1.5 has generics and C# has some more of C++ features compared to Java, but the matter of fact is that both languages are still tradeoffs compared to C++ in terms of productivity and stability rather than a clear step forward.
I would like to see a language that preserves as many features of C++ as possible while adding garbage collection, memory safety, language-based security and guaranteed binary compatibility between platforms/OSes. I don't think managed C++ is "it". Why can't a VM support multiple inheritence? Any pointers?
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!"
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.
When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.
- Convert digital photographs and GPS track logs into annotated photo albums and trip maps
- Examine the availability of 4500 URLs cited in computer science research papers.
- To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.- the *BSD sed implementation.
- The socketpipe zero-overhead network pipe tool.
- The Outwit Windows-Unix shell integration tool suite.
- The fileprune backup file prune utility.
- A device driver for interfacing with my home's alarm system.
In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.#include "/dev/tty"
I have no faith in these OO language crap either. The real world maybe OO, but once your code is compiled, it is going to run us a sequence of statements: i.e., like an imperative language.
Well, DUH. In the end its just ones and zeroes no matter what language you use. OO does not change the way computers operate much, it is a way to help programmers think about the problem domain in a way that hopefully is a bit easier for most of us. Jeez.
If you don't like it because it cramps your "bursting with geek studliness" style, that's fine. But if you don't even understand what high level languages are for, I doubt you know what you are doing.
Being bitter is drinking poison and hoping someone else will die
I was just wondering where I could get a C compiler.
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.
I know the quote was wrong, and thus the entire discussion is senseless. But still, there are things to say about a language dying: (computer) languages do not die. Period. All of the languages ever invented are still used somewhere. People still use FORTRAN, COBOL, C64 BASIC and all kinds of other weird languages.
Besides, why would one of the most powerful and widely used and known languages (C) die? It is like saying noone uses a normal screwdriver anymore, just because they own a battery-powered one. Sometimes you just use the normal one, because it is easier, faster and it just works.
-- The Internet is a too slow way of doing things, you'd never do without it.
Sure, but this helps only if you can assume that those compiled C and C++ binaries are already installed on the user's computer. The main point of "compile once, run anywhere" is to be able to distribute a compiled program that will run anywhere. Of course in DotGNU, we don't define "anywhere" as narrowly as the Microsoft monopolists do:
Unlike Microsoft's C compiler, whose output will only run on i386-based Microsoft Windows systems, our compiler turns portable ANSI C code into a truly portable executable that will run any platform that has a CLR ("Common Language Runtime"), regardless whether the system is 32-bit or 64-bit, little-endian or big.
Or is it because of some form of hatred towards C#
No. It's because there's a lot of C code out there that people might want to use from C# and other modern languages. Throwing that C code away and re-implementing in another language would be a waste of time.
On the one hand, the article here is misleading. The slashdot news story it cites claims 'c' is dying, but the article that news story cites does not. So the cited story got twisted on slashdot.
So now we have a new slashdot story running with the mistake...
The majority of CPUs in today's world are not running desktops.
Things with C
Linux
compilers
Automotive
engine controllers
ABS controllers
Airbag controllers
Memory seat controllers
etc...
Calculators
desktop BIOS and chipsets
Cell phones
etc...
Most code written to run on the hardware is written in C. So the contention being refuted is faulty in the first place.
C# whips the tar off of Java (and most non-optimized C code) in most benchmarks. Why? Because it's running on Windows only for these benchmarks. Anyone remember IIS running faster than Apache because of MS taking advantadge of undocumented platform APIs?
Do you think C# on Linux/BSD/*nix is going to be near as fast as C# on Windows? Think again. It may eventually catch up, but not before it gets a reputation for being dog slow. (See Java as an example).
C is really fast. If you know how to optimize it, nothing can beat it (except assember or some special Fortran routines, if it works for you project). If you ~don't~ know how to optimize C really well, Java (anywhere) and C# (on Win32) can be as fast or faster. Usually is much faster, these days.
Java runs, with very little effort, on every major OS and platform out there. (And yes, I do this for a living). I work at SAS (http://www.sas.com) and we ship the same codebase on Win32, HP-UX, HPi, Linux, Solaris, AIX, etc. The advances in the Just In Time compilers has made a huge difference in performance. (There are some differences in the major J2EE environments, but even that is addressable and minor compared to an entire product port).
Yes, it's still true that a programming guru can write some smoking C code, but Joe Sixpack Programmer usually can't beat Java's performance. And yes, I'm talking big number crunching. At a prior job (at a biotech), we crunched Big Numbers (two month runs on a grid of machines) and Java did a very respectable job. We spent our time improving algorythms (from a bio point of view, not a C/ASM point of view).
The C#/Mono crowd is spending a lot of mindshare in making sure that MS's latest language will run anywhere, and that's great. I am glad they are doing it and applaud the effort.
But Java is far and away the fastest true cross platform language out there right now. It's got the best cross platform enterprise environments available. If you are looking the most speed ~and~ portability, the King isn't dead yet. :)
Agile Artisans