Forgot your password?
Programming IT Technology

C Alive and Well Thanks to Portable.NET 582

Posted by michael
from the alive-and-well-anyway-in-case-you-hadn't-noticed dept.
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."
This discussion has been archived. No new comments can be posted.

C Alive and Well Thanks to Portable.NET

Comments Filter:
  • by gid13 (620803) on Monday March 15, 2004 @03:06AM (#8566317)
    ...stop telling me things are DYING, maybe let me know when they're DEAD.
    • by MukiMuki (692124) on Monday March 15, 2004 @03:20AM (#8566389)
      Isn't this the part where a troll brings in the "NetBSD is dying article" with C as the replacement modifier value? C'mon, they HAVE to have an atomatic generator by NOW.
      • by stephenisu (580105) on Monday March 15, 2004 @01:18PM (#8569482)
        It is now official - Netcraft has confirmed: C is dying Yet another crippling bombshell hit the beleaguered C community when recently IDC confirmed that C accounts for less than a fraction of 1 percent of all languages. Coming on the heels of the latest Netcraft survey which plainly states that C has lost more market share, this news serves to reinforce what we've known all along. C is collapsing in complete disarray, as fittingly exemplified by failing dead last [] in the recent Sys Admin comprehensive networking test.

        You don't need to be a Kreskin [] to predict C's future. The hand writing is on the wall: C faces a bleak future. In fact there won't be any future at all for C because C is dying. Things are looking very bad for C. As many of us are already aware, C continues to lose market share. Red ink flows like a river of blood. FreeC is the most endangered of them all, having lost 93% of its core developers.

        Let's keep to the facts and look at the numbers.

        OpenC leader Theo states that there are 7000 users of OpenC. How many users of NetC are there? Let's see. The number of OpenC versus NetC posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetC users. C/OS posts on Usenet are about half of the volume of NetC posts. Therefore there are about 700 users of C/OS. A recent article put FreeC at about 80 percent of the C market. Therefore there are (7000+1400+700)*4 = 36400 FreeC users. This is consistent with the number of FreeC Usenet posts.

        Due to the troubles of Walnut Creek, abysmal sales and so on, FreeC went out of business and was taken over by CI who sell another troubled OS. Now CI is also dead, its corpse turned over to yet another charnel house.

        All major surveys show that C has steadily declined in market share. C is very sick and its long term survival prospects are very dim. If C is to survive at all it will be among OS hobbyist dabblers. C continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, C is dead.

        Fact: C is dead
    • by jandersen (462034) on Monday March 15, 2004 @04:43AM (#8566640)

      It is at best stupid to talk about how 'C is dying' anyway, seeing as it is still the most popular language in many areas, as well as the single biggest inspirator for 'new' languages.

      I can't remember how many times the impending deaths of such things as COBOL, FORTRAN, BASIC, mainframes etc etc have been announced, but they are still going strong all of them.

      Following the same arguments, C# and .net are obsolete and dying too..
      • by dnoyeb (547705) on Monday March 15, 2004 @08:11AM (#8567144) Homepage Journal
        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
        engine controllers
        ABS controllers
        Airbag controllers
        Memory seat controllers
        desktop BIOS and chipsets
        Cell phones

        Most code written to run on the hardware is written in C. So the contention being refuted is faulty in the first place.
      • by gauchopuro (613862) on Monday March 15, 2004 @09:13AM (#8567375)
        It is at best stupid to talk about how 'C is dying' anyway, seeing as it is still the most popular language in many areas, as well as the single biggest inspirator for 'new' languages.

        I agree 100% that C is the biggest inspirator for new languages. One can only take being burned by C's shortcomings so much before deciding that there has to be a better way.

    • ...stop telling me things are DYING, maybe let me know when they're DEAD.

      Maybe we could have special section on the main page, sort of like a bullet list, only instead of bullets we have either red (dying) or green (getting better/alive again) graphic's, then we could watch them blinking away as various things die and undie :-D
  • What about C++? (Score:4, Informative)

    by ace123 (758107) <> on Monday March 15, 2004 @03:07AM (#8566322) Homepage
    Isn't C++ widely portable while giving mast if not all of the features of C# (except for being interpreted)
    • Re:What about C++? (Score:3, Insightful)

      by davebrot (464549)
      True enough, but that's not really the point of the posting. Lots of people know how to program C and not C++. Regardless of how one feels about procedural vs. OO languages, a .NET runtime for C does demonstrate the hardiness (or maybe just the deep entrenchment) of C.
      • Re:What about C++? (Score:4, Insightful)

        by Progman3K (515744) on Monday March 15, 2004 @03:56PM (#8571157)
        Believe me or not, I've met a few programmers (I can honestly say 3!) that were able to program in C++, but not in C!

        All three were fresh out of school and were working as professional C++ programmers!

        When I say "unable to program in C", I mean that exactly; they were unable to deal with pointers, didn't understand the basic variable types, couldn't write an application without the Visual C++ application-wizard generating a skeleton for them!

        "What's a main?"

        "ints have a range?"

        "why is my unsigned variable never decrementing to -1?"

        "Pass by reference???" *blank stare*

        If I asked any questions like - "How do you think printf is implemented?"

        I'd get a typical response like "dunno"

        OK you say, printf is big, etc...

        But when I'd ask "What does this code you wrote last month do?" and get "dunno" as an answer, it was sort of shocking.

        You see, I think everyone trying to lower the bar by getting rid of C and anything low-level like that will backfire, if these fresh-out-of-school examples are any indication:

        After finding them so useless at getting the job done except when everything was just about completely pre-chewed and put into their mouths, I did what I had to.

        I laid-off one of them.
        Another left out of boredom and apathy because I gave him the task of fixing his own bugs.

        If we lower the bar, it won't prevent problems from existing and needing to be solved, you see, and only the programmers with TRUE aptitude will succeed, and they won't mind C one bit.

    • Re:What about C++? (Score:5, Insightful)

      by condensate (739026) on Monday March 15, 2004 @03:37AM (#8566444)
      True, and C++ is more than a better C. But how in the world do you do numbercrunching with a bytecode language? Tried to do so once for Java, and I'm NEVER going to do it again. Compilers do exploit the specific processor, VMs can do so, too, but why should I introduce a level of complexity, when I just want my processor to calculate things for me? It doesn't get easier, just more portable, but then, C++ seems fairly portable, using templates all along and letting the compiler do the nasty stuff. This means for C it's going to be macros. But hell, isn't it great when you actually know what happens? If you start out on some byte code language, you actually have no idea about the basics of your system. How can you program this system then? And for the anti-FORTRAN fraction. It is still the fastest thing out there!!! Anyone who tried solving a system of linear equations containing 1000 equations knows what I mean. My eyes still pop out when I see a FORTRAN subroutine at work that will do the job in seconds on a normal PIII desktop. So please stop this thing about dying languages which are in fact not dying but a little hard to cope with. This doesn'd make them old. It's just that some people don't want to go through the trouble of learning them, yet they are simply too good to be left out.
      • Re:What about C++? (Score:3, Interesting)

        by arivanov (12034)
        And for the anti-FORTRAN fraction. It is still the fastest thing out there!!!

        No it is not. Been there. Done it. For ultra fast solving of linear equation systems actually. A good hand coded vector library written in ASM will beat it outright. Been there done it. 12 years ago. Wrote vector libraries for TP which used routines specific to each of the CPUs at the time 286/287 (standard, AMD and Harris), 386/387, 386/IIT and forgot what else (it was just before 486 came out). Took 4 weeks of work to write an

      • Re:What about C++? (Score:3, Insightful)

        by Peorth (719504)
        C++ isn't a "better C", really, so I suppose I'm somewhat in agreement. C++ seriously breaks compatibility with C, of course, though uses roughly the same syntax to extend itself over the top.
        Objective C is compatible with the underlying C (it's compatible with C99 too, last time I checked), while using a different "new" syntax for the object orientation, as well as providing a nifty class library and dynamic type checking.
        In some respects, it's like C#, including the decently poor class library API (compar
    • by Fuzuli (135489) on Monday March 15, 2004 @04:09AM (#8566534)
      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.
      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 .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.
      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 .NET.
      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...
      • "Most of the times, these libraries are not cross platform"
        Well, duh, the claim is c++ is portible not "all libraries that c++ uses are portable"

        Having said that I would say that there are degrees of cross-platform-ness. Java being much closer to the ideal than c++.
      • JAVA only works on one platform, the JVM. And there are so many little differences in JVMs that most java apps of any size I've are anything but "write once, run anywhere".

        Also, if you want protabe C++ code, all you have to do is draw a firm line in your design between platform specfic and the rest of your code.

    • Re:What about C++? (Score:3, Informative)

      by sabre (79070)
      Check out LLVM: []

      It gives the advantages of bytecode compilation (linktime & runtime optimization, JIT compilers, etc) to both C and C++ (using the GCC parsers). In addition it has a powerful interprocedural optimizer, so it generates code that truely thwomps GCC in some cases. :)

  • Er.. (Score:5, Insightful)

    by iswm (727826) on Monday March 15, 2004 @03:10AM (#8566336) Homepage
    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.
    • Re:Er.. (Score:5, Interesting)

      by Graff (532189) on Monday March 15, 2004 @04:52AM (#8566661)
      C is still alive and kickin' in the NIX community I'd say.

      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!
  • C?? (Score:5, Funny)

    by Neo-Rio-101 (700494) on Monday March 15, 2004 @03:10AM (#8566339)

    Yeah, just kill it off already... I wanna go back to using Commodore 64 BASIC.
  • Wow! (Score:4, Funny)

    by stevens (84346) on Monday March 15, 2004 @03:11AM (#8566342) Homepage
    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?
  • by Ratface (21117) on Monday March 15, 2004 @03:11AM (#8566343) Homepage Journal
    Sorry - someone had to say it!
  • by Anonymous Coward on Monday March 15, 2004 @03:12AM (#8566348)
    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.
  • Keep it real... (Score:5, Insightful)

    by seanmcelroy (207852) on Monday March 15, 2004 @03:13AM (#8566353) Homepage Journal
    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.

    Now what a spin. The .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.
    • Re:Keep it real... (Score:5, Insightful)

      by forgoil (104808) on Monday March 15, 2004 @03:40AM (#8566455) Homepage
      Not to mention the fact that the developers of C# (i.e. the people developing the language, not with the language) made sure that one can easily make use of C and C++ code and binaries already in existance. You can already call all the C/C++ APIs.

      I'm not sure or clear of why one would want to code in C instead of C# when developing for a .NET environment (be in Microsoft or Mono or something else). It can't be because you can't make use of already written APIs (since you easily can call them), so we killed that point. It can't be because of the "speed" of C, since it will be running the same IL on the same CLR. We are basically down to the language of C.

      So is this because someone feels that OO could be too big for very small devices (Java MIDP showed us this very clearly, since it is completely missplaced and awful on mobile phones)? I can buy that.

      Or is it because of some form of hatred towards C#? That makes it sad. The APIs for .NET are far better than any C API I've stumbled upon thus far (win32, POSIX, Solaris, GNU, etc), contains a vast amount of useful things, and easily calls unsafe (.NET terminology, look it up if you don't actually know what it means) C/C++ APIs.
      • Re:Keep it real... (Score:3, Insightful)

        by Sique (173459)
        Or is it, because there are lots of work already done in C, and adapting the code to .NET seems more feasable than porting it to C#? Or because the algorithms are given in C, and it makes no sense to reinvent them in C#, because they don't make any usage of an object oriented design? (Think about huge numerical packages.)
      • Re:Keep it real... (Score:4, Insightful)

        by TummyX (84871) on Monday March 15, 2004 @06:09AM (#8566859)
        Um think about it. P/Invoking involves calling native DLLs (meaning you'd need a different binary DLL for each platform). By compiling your C libraries into IL using Portable .NET's C compiler you can distribute one set of binaries for your applications.

        For example, if you need good JPEG decompression routines in your ".net" application you could recompile libjpeg with pnet's cscc compiler and keep your application 100% "managed".

        Far too many people on this thread know *nothing* and are talking crap.
      • by bizcoach (640439) on Monday March 15, 2004 @06:22AM (#8566896) Homepage
        the developers of C# (i.e. the people developing the language, not with the language) made sure that one can easily make use of C and C++ code and binaries already in existance. You can already call all the C/C++ APIs.

        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.

  • by bangular (736791) on Monday March 15, 2004 @03:14AM (#8566357)
    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++.
    • Python does compile to bytecode. It just does not require a separate step to compile to bytecode like java does. If the bytecode is out of date it will be recompiled and used automatically.
    • by infiniti99 (219973) <> on Monday March 15, 2004 @04:31AM (#8566603) Homepage
      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).
    • by SpaghettiPattern (609814) on Monday March 15, 2004 @04:58AM (#8566674)
      C has it's problems.
      C has no problems. It does exactly what it's supposed to do.

      You create problems when using C for business purposes. Business programmers don't want to waste time chasing memory leaks and array overflows.
    • 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
      • by Imperator (17614) <slashdot2@omershenker. n e t> on Monday March 15, 2004 @07:11AM (#8567015)
        at least in the Unix world, is that pretty much every library is written in C

        Actually some of them that look like they're written in C are actually written in C++. They're just careful to make sure that all the public interfaces are extern "C". They can then use whatever fancy C++ features they want in implementing the library.

        I think this is one of the real strengths of C: because the ABI is so simple, pretty much anything can link to C and almost anything can create C bindings.

    • by be-fan (61476) on Monday March 15, 2004 @12:01PM (#8568699)
      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.
      Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project [] for an OS written in a safe language.

      One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code.
      I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.

      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.
      Common Lisp []
      Another Common Lisp []
      Ocaml []
      Scheme []
      Dylan []
      Another Dylan []

      We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.
  • Huh? (Score:3, Funny)

    by drgonzo59 (747139) on Monday March 15, 2004 @03:16AM (#8566365)
    I wonder if Microsoft can then compile the .NET framework into IL and run .NET (on top of .NET)* ?

    In the meantime I'll just risk being labeled "old-fashioned" and compile C straight to binary

  • by Biotech9 (704202) on Monday March 15, 2004 @03:17AM (#8566369) Homepage
    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.

    • Insightful (Score:5, Interesting)

      by SuperKendall (25149) on Monday March 15, 2004 @03:20AM (#8566387)
      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.
  • by VoidEngineer (633446) on Monday March 15, 2004 @03:20AM (#8566388)
    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?).
  • by Teddy Beartuzzi (727169) on Monday March 15, 2004 @03:21AM (#8566392) Journal
    It's just pining for the fjords.
  • by aarondsouza (96916) on Monday March 15, 2004 @03:36AM (#8566436)
    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.
    • there isn't any other language out there that is as efficient (both size *and* speed count) as well optimized C code
      Sure there is. C++ (with exceptions and RTTI disabled) is just as efficient as C [1], plus it's type-safe, has nested namespaces, classes & templates.

      [1] as long as you disable exceptions & RTTI and stay away from virtual/multiple inheritance & pointers to member functions.

  • C is Dead (Score:5, Funny)

    by WankersRevenge (452399) on Monday March 15, 2004 @03:38AM (#8566448)
    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?
  • by StevenMaurer (115071) on Monday March 15, 2004 @03:43AM (#8566461) Homepage 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.)

  • by idiot900 (166952) on Monday March 15, 2004 @03:43AM (#8566462)
    Does this include *all* of C? How do they compile the following C features into VM bytecode?

    - Pointer arithmetic
    - Hardcoded type sizes instead of using sizeof() (i.e. assuming sizeof(int) == 4)
    - Lax rules for casting
    - And so on
    • Does this include *all* of C? How do they compile the following C features into VM bytecode?

      - Pointer arithmetic
      A: YES
      - Hardcoded type sizes instead of using sizeof() (i.e. assuming sizeof(int) == 4)
      A: WTF ? .. C never had that ... C never had a fixed size for integers ... anyway malloc(20) will work
      - Lax rules for casting
      A: YES .. had to work a lot to get those function pointers castable !!
      - And so on
      A: Hey, porting glibc ... remember
  • Why C needs help (Score:5, Insightful)

    by ttfkam (37064) on Monday March 15, 2004 @03:58AM (#8566504) Homepage Journal
    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?
    Or read a different way, would you rather program to a uniform API for GUIs that are accessible to many languages including C# or the huge Free Software diversity of GUI APIs that are all incompatible but still just make a button and a checkbox.

    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.

    • Re:Why C needs help (Score:3, Interesting)

      by humankind (704050)
      C gives you huge control over your operating environment, without obligatory overhead. This is a tremendous advantage in any scenario where you need stability and performance. Higher-level languages make you much more dependent upon the environment.

      I wrote a shopping cart application that uses 23K of RAM and processes more than $2M in transactions online a week. I can handle more than 300 times the traffic than a comparable Windows server with this application and it's rock solid. I don't worry about bugs
  • by iamacat (583406) on Monday March 15, 2004 @04:26AM (#8566589)
    ... 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?
  • by lordholm (649770) on Monday March 15, 2004 @04:26AM (#8566590) Homepage
    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!
  • by cyberjessy (444290) on Monday March 15, 2004 @04:31AM (#8566607) Homepage
    I have been doing Windows development for quite some time now. Both low-level and applications(these days).

    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.

    There is no point in a .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!

    Maybe i exagerated when i said no point. Maybe for small projects, components that need to interoperate with the rest of .Net. But not for anything big.

  • by Otis_INF (130595) on Monday March 15, 2004 @04:47AM (#8566649) Homepage
    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.

    All languages on .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.

    That will not always work in all cases.

    And what about interlanguage operability? An assembly in IL can be referenced from any .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?
  • by Diomidis Spinellis (661697) on Monday March 15, 2004 @04:47AM (#8566650) Homepage
    Judging from some previous comments, I see that some fail to grasp that modern computer languages form a large ecosystem. Each language has its purpose, and one can not easily dismiss a language as dead, just because some other, ostensibly more powerful language has appeared on the block. Monkeys, whales, cockroaches, ants, and plants continue to coexist with humans.

    When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

    #include "/dev/tty"

  • popularity (Score:3, Insightful)

    by mpmansell (118934) on Monday March 15, 2004 @04:52AM (#8566662)
    I suspect that when people talk about the popularity of a language fading, they are really talking about the percentage of developers using it.

    This doesn't really tell anyone if the number of people using the language has changed. Given the explosion of programmers in recent years, be they professionally trained, or weekend dabblers, it is likely that they are using the current faddy or new languages, like Java, C# or VisualBASIC (not meant as flamebait; I use them myself when engineering requirements suggest them). This for the most part because their emphasis is on making pretty UIs and not any of the more traditional processing or server applications.

    This 'explosion' of users with new languages doesn't mean that the old Fortran, Cobol or C applications will immediately be re-written in BoltsN.Nuts or whatever the latest and greatest is. These people will, quite sensibly, plod along with the tried and tested and will probably even continue developing within these skillsets.

    The requirements for these skills may well have stayed the same, while the requirement for GUI apps and amateur (some calling themselves professional) developers has increased.

    Before anyone can say a language is dying, lets see the figures. For all we know, these dying languages could even be growing (in numbers, if not percentage). Besides which, who should really give a damn?? If it works for you, use it. If it doesn't, but you're not harmed by it, live with the fact that the Borg haven't yet asssimilated us all :)
  • The real question (Score:3, Insightful)

    by jandersen (462034) on Monday March 15, 2004 @04:55AM (#8566665)
    "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."

    No - that's not the real question; it's: 'Oh no, not yet another C-like language!?'

    What's the point, actually? C# is not something new, it's just an attempt to 'get the colour exactly the right shade of pink'. The truth is - C (the language) is precisely what it should be. So perhaps it would be nice to protect the more inept programmers against themselves, but that is simply a question of the runtime- and development environment, or perhaps some improved libraries.

    As I always say: a good programmer can write good code in any language, and a bad programmer will not write good code in any language; it's as simple as that, really. This is because good programming is about good coding and debugging practice, both of which are independent of whichever language you use.
  • by selderrr (523988) on Monday March 15, 2004 @05:02AM (#8566687) Journal
    It's a common misconception that you need a ton of API's. up to a few years back, I also fell for the DEVStudio GUI builder, the MFC framework, and the libraries that orbit it. After 5 years of trying to get a hold on the beast, I met someone who had stepped back from all frameworks, and went back to ordinary console C and C++. I walked his footsteps, and my apps got reduced to 15% of their original size. Okay, the dummy users needed a few days more to learn the app, but with solid documentation, this was not an issue. And after 2 months, some RealBasic nutcase wrote a GUI wrapper on top of it in 1 week. Perfect !
  • Thank God! (Score:5, Funny)

    by jasonditz (597385) on Monday March 15, 2004 @05:13AM (#8566713) Homepage
    I was just wondering [] where I could get a C compiler.
  • by humankind (704050) on Monday March 15, 2004 @05:40AM (#8566778) Journal
    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.
    • You Sound Like (Score:3, Informative)

      by Mark_MF-WN (678030)
      You sound like an assembly-language advocate. They too are known for praising the silliest qualities of their chosen language.

      C's only strengths are speed and easy access to hardware.

      String boundary checking SHOULD be a feature of any modern language -- or do you enjoy buffer overflow exploits?

  • by DerPflanz (525793) <[ln.tfoseirf] [ta] [trab]> on Monday March 15, 2004 @05:43AM (#8566783) Homepage

    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.

  • Poor Perspective (Score:3, Insightful)

    by Mark_MF-WN (678030) on Monday March 15, 2004 @07:32AM (#8567053)
    Why would the rampant success of bytecode and interpreted languages have any effect on C? Don't get me wrong -- Java, Python, and PHP are three of the best things to EVER happen to Software Development. But that hardly makes C any less important.

    It's like comparing the importance of your spinal cord to the importance of your kidneys. They both kick ass and serve a particular purpose; in many cases they complement each other wonderfully. And let's not forget that Python and Java both use C as an extending languge.

  • by gatkinso (15975) on Monday March 15, 2004 @07:33AM (#8567056)
    Way to completely miss the point of language independence.

  • Java vs C vs C# (Score:5, Informative)

    by jarich (733129) on Monday March 15, 2004 @08:34AM (#8567203) Homepage Journal
    A few thoughts....

    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 ( 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. :)

  • by caudron (466327) on Monday March 15, 2004 @08:55AM (#8567300) Homepage
    The article is referring to the recent claim that Miguel said that "C is dead". The problem is that it's quoted out of context and is getting rehashed so much that people are gonna forget that it was never actually said.

    This article implies a great deal, but the reality is that Miguel never said C was dead. He said that to him C was dead, meaning that he intended to focus his programming time on C#. Pretty reasonable statement given that he's in charge of a project that's porting it to linux.

    Surprisingly to the language zealots among us, Miguel is allowed to write code in whatever language pleases him.
  • The point? (Score:4, Insightful)

    by DrXym (126579) on Monday March 15, 2004 @08:57AM (#8567308)
    What is the point of a C which presumably has been stripped of low level control, pointers etc. to run on .NET? You don't even benefit from any speed advantage because you're running through an interpretter / JIT.

    Having seen side by side comparisons of J#, C# & VB running on .NET it's hard to see why multiple languages exist at all. Any reason for using one language over another has just about disappeared. It is the same code using the same assemblies, with slightly different syntax. The language itself has become an irrelevance.

  • by SloppyElvis (450156) on Monday March 15, 2004 @09:49AM (#8567562)
    Ok, so I think the writing on the wall reads, "M$ will be requiring code to run through the .NET CLR", if it is to run on Windows.

    So, in response, we have C compiling to bytecode. But, Longhorn will require bytecode assemblies to be signed; I suppose that could be built into the compiler as well (else wouldn't we lose portability?)

    I was thinking along these lines a while back, and thought to myself, "What's to stop somebody from writing an interpreter for any language (I was thinking scripting at the time) that will run as a .NET app? [Ruby was on my mind]

    What's the impact of doing this, you ask? Well, if the interpreter itself is the signed certificate-backed secure executable, then any little scriptlet or homebrew app could be run without being digitally signed!

    To me that allows a fairly obvious circumvention of Palladium, and "trustworthy computing" is out the door.
  • What about LLVM? (Score:3, Interesting)

    by sabre (79070) on Monday March 15, 2004 @10:27AM (#8567788) Homepage
    Check out LLVM: []

    It gives the advantages of bytecode compilation (linktime & runtime optimization, JIT compilers, etc) to both C and C++ (using the GCC parsers). In addition it has a powerful interprocedural optimizer, so it generates code that truely thwomps GCC in some cases. :)

  • by BRSQUIRRL (69271) on Monday March 15, 2004 @10:36AM (#8567872)
    would you rather program against the pitiful number API's that come with C#

    Completely ignoring the fact that no APIs could "come with" C# because C# is just a one of many languages that compiles to .NET CLR bytecode (thanks once again for showing your complete ignorance of .NET)...I have written a lot of .NET apps and have yet to find myself needing some functionality not already provided somewhere in the .NET class library. It is (by far) the richest set of application APIs I have ever developed with.

Nothing is rich but the inexhaustible wealth of nature. She shows us only surfaces, but she is a million fathoms deep. -- Ralph Waldo Emerson