C Alive and Well Thanks to Portable.NET 582
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."
Re:Wow! (Score:4, Interesting)
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.
Insightful (Score:5, Interesting)
*yawn* (Score:2, Interesting)
*shrug*... bring it on.
Re: *yawn* (Score:1, Interesting)
> I'll start worrying when I see entire OS's and their requisite device drivers written completely in a bytecode language.
I don't suppose you'll like my idea for a metalanguage, which can be interpreted at run time into the bytecode language of your favorite bytecode interpreter?
It's Dead Jim (Score:2, Interesting)
I have never used, and will never use this bytecode languages running on VMs. I won't the minimum distance between my program and the machine instructions. Currently, C is the best language for this purpose.
Unfortunately, a lot of CS courses are teaching people the importance of "managed code" and "strong typing" etc. I say to hell with that. If I feel like messing up with memory at AF345F12:BA231DCE then I shell do so. I don't want to hide behind "type safety". I know what I am doing.
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. Not to say that people have not tried to build processors which had OO machine code, but none of them caught on. I work mainly with the Intel architecture. It's not natively OO.
Long live C
Didn't RTFA but have some questions anyway :) (Score:3, Interesting)
- Pointer arithmetic
- Hardcoded type sizes instead of using sizeof() (i.e. assuming sizeof(int) == 4)
- Lax rules for casting
- And so on
Re:Adaption, but.. (Score:2, Interesting)
Who would have though that a mainframe manufacturer would keep prompting dead langauges? <g>
Whilst Algol isn't there, Oberon [oberon.ethz.ch] is, as is Ada [af.mil], a shareware version of Forth [dataman.ro], Haskell [galois.com], Eifell [galois.com], Pascal [qut.edu.au], Perl [activestate.com], Python [python.net] (twice [activestate.com]) and SmallTalk [smallscript.net]
FUD again from MS zeelots ! (Score:1, Interesting)
Did Java kill C since nearly a decade it is here ? No ! So there is no doubt that a windows only platform (.net) can kill a multiplatform language !
If there is a platform that has deprecate C/C++ in lots of enterprise developpment it is more Java itself. Ey guys, look at the realworld !
Java has replace lots C/C++ developement just because it is much easier to setup and to maintain with an "average" skill (you got plenty of free & free solutions as well as bullet proofed comercial solutions that fits every needs).
Java is also the key to open the server side OS. Because by choosing Java enterprise can shift to any supported OS they want depending on their TCO for instance. And there Linux win in most situations here !
So Java offer OS choice and Linux OS solution
Personally, i've worked with
I do not realy understand people working on mono (which is a nonsense by the way), why don't they go and help FSF's classpath project instead if they want a realy free implementation of some advanced language & VM ? Ey, FSF ! Know those guy
So if you want to help Linux to get a truly independent, full GPLed & fully compatible solution : Go and help FSF's CLASSPATH PROJECT [gnu.org] ! They do need your skills !
Re:Let it die! (Score:5, Interesting)
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.
languages are tools god dammit (Score:5, Interesting)
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!
Re:C's not dead because nothing better.... (Score:5, Interesting)
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 [trolltech.com]. 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).
C is alive, not becoz of Portable.Net (Score:3, Interesting)
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
yeah no kidding. (Score:2, Interesting)
of course, i work in embedded, so i'm not necessarily in a position to judge windows. in my world, C still rules the roost, and probably will for a loooong time.
This is more Interesting that C on .NET (Score:1, Interesting)
Chatlog [win.co.nz]
[04:22] <rhysw> 2 years ago, I was working on a virtual machine that could run C. Like, real C. Not pansy fixed up clean C, but the nasty pointer stuff.
[04:22] <ajmitch> ooh
[04:23] <ajmitch> how well did it work?
[04:23] <rhysw> I called it "Jindalee", after the place where I lived
[04:23] <rhysw> It worked pretty well except for one thing
[04:23] <rhysw> The VM was very efficient, but also *very* funky in its design. Writing a C compiler for it was a total bitch.
[04:24] <rhysw> But now that I have treecc, and 2 years of IL knowledge under the cap, I may be able to dust it off and build a very nice VM.
[04:24] <ajmitch> excellent!
[04:24] <ajmitch> i guess it'll require deep C & CS knowledge to hack on?
[04:25] <rhysw> No more than needed for pnet, actually. The core funky idea is easy enough to understand.
[04:25] <rhysw> Best of all, the entire engine is under 100k in size.
[04:25] <ajmitch> hmm, ok, i should see if i can understand it
[04:25] <rhysw> ok - I'll lay it on you and twist your brain a bit, shall I?
[04:25] <ajmitch> alright
[04:26] <ajmitch> my brain's already fairly twisted from trying to debug & polish this python app
[04:26] <rhysw> Keep in mind that this is the original Jindalee, not the new one
[04:26] <ajmitch> sure
[04:27] <rhysw> VM's like Java have a problem
[04:27] <rhysw> But what if there was no way to do that (push int, pop pointer)? Then there would be no problem, right?
[04:28] <ajmitch> sure..
[04:28] <rhysw> So, I created an engine with two stacks, instead of one. You can push integers on one stack, but only pop pointers from the other. Viola - no way to cast an int to a pointer and circumvent security. And no bytecode verifier needed either.
[04:29] <ajmitch> funky
[04:29] <rhysw> exactly - no one else had done that.
[04:29] <ajmitch> surprising
[04:30] <ajmitch> so how'd code in the vm go interfacing to system libs?
[04:30] <rhysw> it was kinda icky
[04:31] <rhysw> anyway - I may dust it off if I get some time
[04:32] <ajmitch> do so, please!
[04:33] <ajmitch> even if you just put up a tarball of it somewhere
[04:33] <rhysw> it needs a lot of cleaning up first, but it may make an appearance in the near future
[04:33] <ajmitch> you've done some amazing work with pnet, this'd be a great help as well
[04:34] <ajmitch> got any ideas on how to get more coders involved?
[04:37] <rhysw> i wish i did - it would certainly solve my depression problem
And how is this going to work? Paradigm clash! (Score:5, Interesting)
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
Re:Er.. (Score:5, Interesting)
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!
Re:And how is this going to work? Paradigm clash! (Score:2, Interesting)
Read Pnet C ABI [gnu.org]
litmus test for programmers (Score:5, Interesting)
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.
Re:Er.. (Score:2, Interesting)
Re:C's not dead because nothing better.... (Score:3, Interesting)
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.
Re:Why C needs help (Score:3, Interesting)
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 in the API; I don't worry about stability issues. Things work the way they should.
Then again, I get paid to get things done, not by the hour, so that's why I work with C.
Re:What about C++? (Score:3, Interesting)
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 and optimize instruction ordering to keep the puny 15 byte 286 pipeline always full. The result was 4-5 times faster then fortran for the same platform. And 100 times more usefull because you could use them in a proper high level language with OO.
Re:Please stop C++ calling portable (Score:2, Interesting)
Oh no not pointers void * (Score:1, Interesting)
Looking at code in the real world.... Well that's something totally different. It's like getting out of kindergarden armed with the certainty that people would never lie, because it's wrong, and walking into the world championship of poker. Because void * might not be every bit as common as bluffing in poker, it's not far off.
And another apocryphal quote is born... (Score:3, Interesting)
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.
Re:Not that simple (Score:2, Interesting)
Re:What about C++? (Score:4, Interesting)
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.
Re:What about C++? (Score:3, Interesting)
Re:What about C++? (Score:3, Interesting)
Yes, it is a more bloated, complex and difficult to learn version of C.
No, I have always taken it that C++ is good if you dont know C and C is good if you dont know C++. Once you learn the one you become suddendly jaded towards the other.
Language Piggy-Backing (Score:3, Interesting)
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
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)
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.
-Chris
Garbage Collection in C (Score:2, Interesting)
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Re:C's not dead because nothing better.... (Score:2, Interesting)
Sure it does, parts of its standard library are moronic.
Business programmers don't want to waste time chasing memory leaks and array overflows.
C does not inherently cause memory leaks and array overflows. Programmers cause memory leaks and array overflows, C just doesn't prevent them from doing so.
I use C++ every day, and while it's not the same, it's close enough to fall under the same criticism. I haven't had a memory leak or array overflow in a very long time. It's trivial to avoid them.
So why are there so many? Lack of skill, lack of attention. This is why you wouldn't use them for business purposes, you have to hire more expensive programmers.
Java GUI APIs (Score:3, Interesting)
This does not diminish the fact that AWT was the first Java GUI API. It had limitations. It was redesigned to be truly cross-platform and dubbed Swing. As far as the API is concerned, I happen to like the Swing library. Is it "THE ONE TRUE GUI API?" Of course not. Nothing is or ever will be. It was the best they could come up with at the time. Now, when someone learns the standard Java GUI API (or just about any other Java API for that matter), they can transfer those skills to other Java projects much more easily than C coders can in C projects.
SWT? A nice start. It is not as complete, does not run on as many platforms, nor is as widely used as Swing. But it shows promise. In five more years, who knows? That's the point. Right now, there is a standard API that everyone knows and other APIs (that aren't drastically different from the AWT/Swing API by the way) being tried out to find better ways of doing things.
Mono's choice of GTK# is in my opinion a bad move. It's also unfortunate that Microsoft hasn't opened up the APIs for the Windows GUI libraries. I understand their reasons for doing it (Microsoft patent threats), but the culture of C is too strong. Instead of writing a new, GUI toolkit agnostic interface API, they intimately tied it GTK.
C and the programming culture it fosters is building on sand; New APIs are constantly (and in my opinion, unnecessarily) being written all of the time, but there's no common base for others to work on nor to use as a base API design reference. Imagine how much more software would be written if folks didn't have to battle over GTK/Qt, MySQL/PostgreSQL/ODBC client libraries, ALSA/OSS, etc.? Would it be so terrible to tell people, "OpenGL is the standard API interface for 2D graphics in C. How you implement the OpenGL layer is up to you, but use the standard header files so that people can just recompile/relink to use a different implementation.
Don't think it's necessary? Let's look at the history of UNIX, the original C program. The API wasn't standardized and set in stone. Different vendors went their own way in an attempt to lock the others out of their turf. UNIX programs commonly became a mess of #ifdef statements. The Windows came in touting a common API for Windows with COM. Any language (well, the common ones... VB, C, C++, etc.) could use these objects. They had a well-defined API. New implementations (eg. Perl for Windows) could be modified to access these objects as well. It didn't matter what language the COM object was written in. It didn't matter what language you were using. Write to the interface and be done with it. COM had warts. Everything does.
The C community on the other hand just sticks its head in the sand and collectively says, "Look! They didn't do it perfectly. They suck! We rule!"
The C community should be saying, "Look! None of us did it perfectly. Let's make our baby better by taking some of their good ideas and incorporating a bunch of our own."
Mono and Java have warts, but at least they're trying. What's C got show for thirty years? Variable length arrays in function declarations? That is the best thing anyone could come up with for C99? Hey folks! There's an elephant in the corner! It's name is "incomplete standard library." I know no one wants to talk about it, but it's there and taking up too much space at the party!
Nope. (Score:1, Interesting)
I like the aesthetic of the voice from the void. The only information it carries with it is its message.
Plus, it's trivial to dribble out stuff that gets modded to +5 when you can start at +2. As an AC, even having something you think worthwhile isn't enough. Their's timing and positioning to consider.
Then there is the positive reinforcement factor. If people see stuff as modded up +5, that's also decent, from an AC, they might be more likely to browse AC's when they're modderating. Which might slightly increase the variance of popular ideology in this venue.
Anonymous isn't just for cowards anymore.
He, he. (Score:2, Interesting)
1. Bootstraping. The c# compiler in Mono is written in
2. Your argument: "the first Java compiler." Tell you what: sometimes, the first XXX compiler is written in XXX and bootstraps itself. Even some of the first C compilers were written in C. Many assemblers before it were written in assembly language.
2a. the word bootstrap comes from "lifting onself by steping on it's own boot straps." magic, eh?
3. (Shrek citation) you and what army? (/Shrek) I was being caustic; you are mentioning being violent. I can dance the dance, too. Just invite me and we'll tango.
4. ok, so I'll take the discussion again, this time from the beginning, let's see if we understand each ohter.
4a. bangular complained that many modern languages were either scripting (like perl or python) or bytecode languages, so you could not write an OS kernel in it (unlike C, C++,
4b. Ambassador Kosh pointed out that python also is a bytecode-language (and altough he did not mention it, perl is a bytecode-language, too)
4c. you said (assuming he [Kosh?] was talking about x86) bytecode could not run in raw machines ; yes it can't run directly in a x86 machine, but it can run in a specialized processor; but -- a JIT compiler, or an AOT (ahead-of-time) compiler (like gcj) can compile bytecode into machine code easily. You have to remember bytecode is just another representation (direct translation) of (some) assembly language.
5. Here starts you succession of mistakes, that lead to my header and footer in the response I wrote:
5a. you wrote "C and Assembler are what make the computer world run". nope. engineering make the computer world run. many applications are still in COBOL, FORTRAN, and lots of it, today is in Java, etc. Down to the wire level, yeah, there is lots of C and assembler, but they are *not* cost-viable to make many commercial systems. just OS-level software (database management systems, etc). And some are not -- SAP DB is written in Pascal; many MacOS programs were, too,...
5b. you wrote "You can't make Java in Java". bootstraping. bootstraping.
5c. you wrote "C turns directly into executable binary (...). Java cannot". wrong.
5d. you wrote "I suppose that if you were insane enough, you could make a bytecode to opcode converter"... no need to be insane; see what's done at transmeta, ikvm, any JIT compiler, etc. etc...
5e. you continued "but then you lose 100% of the point of the langauge" (sic). wrong, the point of a programming language is to show some abstraction in a clear way. p. ex, C++ classes show the abstraction of classes of real-world objects and the operations that can be effected in those objects belonging to those classes... if you translate it into bytecode, machine language *or* database-description to generate some tables in a RDBMS, it's not differente because of the target language; you did not lose the "point" of C++. So, if you get some JVM bytecode and translate it into
5f. you went on "probably" (lose) "a lot of the efficiency", yeah, some of the efficiency, maybe; but you gain other knowledge that you can use to profile-and-optimize better than any hand-optimization. This will absorb most of the cost of the translation, and, in some cases, the dynamic translation techniques can make your program run even *faster* than the native/compiled version!
5g. you ended the phrase with "and at that point you may as well use C". no, you may not, because C is not *very good* at OOP, or functional programming, or whatever other paradigm you need to express the domain of your problem so a compiler can give you an efficient program to run as a response.
6. as you see, from 5a to 5g, you said seven distinct things in your paragraph, all wrong, all in need
C isn't dead yet. Someone should shoot it. (Score:2, Interesting)
Almost all extant C practitioners would benefit greatly if they gradually abandoned C-style and learned multi-paradigm C++. The world would be a better place.
This is not a troll, and before all of you fundamentalist fanatics pull out your flamethrowers, inform yourselves:
C++ FAQ [att.com]
C vs. C++ [cuj.com]
The case for the continued existence of C is tenuous at best.