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?
Sorry - someone had to say it!
A little planning goes a long way...
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++.
In the meantime I'll just risk being labeled "old-fashioned" and compile C straight to binary
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.
Remember when punch cards went obsolete?
:'(
...
Yes.
I'm old enough where my toddler drinks Pediasure, my wife drinks Boost (to give her nutrients during her pregnancy), and I'm on Slimfast.
I'll cry myself to sleep tonight
I still use punch cards, you insensitive clod!
As for Fortran and COBOL, Fortan is still an entry requirement to the California college system, and COBOL is still everywhere - deeply embedded into the payroll and employment operations of many businesses. And there are still vestiges of punch cards too - Scantrons and the like. So things don't die as easily as you might think. Much as we sometimes wish them away, they hang on.
If my answers frighten you, stop asking scary questions.
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.
It seems to me (even with my limited knowledge of programming and software engineering) that when such statements are made about the death (or undeath...mmm...CZombie...."HEADERS....HEADERSSS") , the idea that C# has its place in fitting in with the .NET framework, C has its place in things like...say...stuff like the Linux kernel (though that isn't near its only use), Java and it's being cross platform, etc is totally ignored.
Just because you can hammer in a screw if you try hard enough doesn't mean the screw driver is dead.
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.
I'll start worrying when I see entire OS's and their requisite device drivers written completely in a bytecode language.
*shrug*... bring it on.
http://cat.nyu.edu/~meyer/jasmin/
"Fortan is still an entry requirement to the California college system"
where can I get some of whatever you're smoking? there are classes where it's used, for sure, but "entry requirement"? no.
However, you should check News.Google.com frequently in case the world ended and no one told you.
> As a Christian, I won't write anything in C (obviously) [...] and do you think that these systems are going to be ported to Java or BASH?
As a Christian, you should clearly support J4V4 in all things.
Sheesh, evil *and* a jerk. -- Jade
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.
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
Indefinitely Detained US Citizen
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"
So, by that argument, shouldn't Java and C# both have been stillborn? Both piggy back on VMs and are the same 'weird' combination?? :)
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.)
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
Who would have though that a mainframe manufacturer would keep prompting dead langauges? <g>
Whilst Algol isn't there, Oberon is, as is Ada, a shareware version of Forth, Haskell, Eifell, Pascal, Perl, Python (twice) and SmallTalk
Screw that! We need more programmers aware of vulnerabilities in systems and to be able to deal with it. Dumbing down a language at the expensive of performance is only going to dumb down the programmers. Well, to a point. My ideal programming language would be something that allows me to do practically anything with it and leaving its internals exposed. You can program with a safe subset if you're beginning, but you can then expand to advanced programming without the language limiting what you can do.
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.
There are python bindings for kde, as well as many others.
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
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.
JVM doesn't have any pointer operations ... IL does .
...
Which means you get a set of pointers which play nice
Quidquid latine dictum sit, altum videtur
... 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!"
Well, couple years ago i was really keen on becoming a 100% C++ writer and ditch my C habits entirely.
Due to the nature of most of my projects, like 90% of my time was spent writing wrappers for all sorts of C-style API interfaces.
Finally i gave up and embraced the zen - pick the right tool for the right job. Being proficient with all sorts of tools helps too.
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Phew!! Thank god for your comment. It saved me a lot of typing :)
:)
On the subject of careless and stupid programmers with C, how about starting a movement to execute people who ignore warnings because they are only 'warnings'
C is a gift from the Gods.
C++ is a gift from the Devil.
I have been doing Windows development for quite some time now. Both low-level and applications(these days).
.Net C compiler. If you are writing applications its better to use Java or C# anyday. C code does become unmanageable(pun intented) as the project size increases. You need all of encapsulation and inheritance to avoid nightmares of one huge gorilla staring at you!
.Net. But not for anything big.
C will not die becoz,
Most of the real high performance stuff is still written in C. Take Windows drivers for example. The only other option would be C++, but then when it gets down to that level you try to squeeze out every bit of performance. What I have noticed it that when you look at the complexity of writing a Windows device driver, the relative complexity of C versus C++ becomes a non-issue in most cases.
You cant write OS/drivers in bytecodes.
But:
There is no point in a
Maybe i exagerated when i said no point. Maybe for small projects, components that need to interoperate with the rest of
Life is just a conviction.
even in the windows world, i'm still seeing *FAAAR* more c/c++ work than anything else around.
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.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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 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
Remember, a language does not cause overflows - careless and stupid programmers do.
:-)
But why have a language that enables the possibility for careless and stupid programmers like myself to do overflows?
"Sir, perhaps its the fact that we put the self destruct button next to the light button on our new combat vehicle that causes a large number of them to explode?"
"Button proximity does not cause explosions! Careless operators cause explosions!!"
When I subscribed to Bugtraq, it seemed most of the vulnerabilites discovered (a couple per day) was caused by buffer overflows. The number of vulnerabilites discovered in Java systems (for instance) were rather few, and tended to be for things like DOS attacks, not getting your whole system security compromised.
Not that I think C is going anywhere, it is still going strong in Unix/LInux land and I like the fact that there are many different languages around. Just commenting on that particular sentence above.
Being bitter is drinking poison and hoping someone else will die
"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.
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 !
When will I end this grieving ? When will my future begin ?
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.
I used to love C, but then I found something much better: Assembly language; pure and clean machine code. It has lots of advantages:
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.
"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++.
Uh, you can't run bytecode on a raw machine. /.
Yes you can. There are several java-bytecode hardware microprocessors.
C and Assembler are what make the computer world run.
false. C and assembler are 20%-100% faster to execute, but 1000%-10000% slower to develop in.
You can't make Java in Java.
Yes you can. *and* you can make csc in c# (see here)
C turns directly into executable binary (or object files then linked into executables). Java cannot.
Look up gcj.
I suppose that if you were insane enough, you could make a bytecode to opcode converter, but then you lose 100% of the point of the langauge, probably a lot of the efficiency, and at that point you may as well use C.
As we were in the subject of python, look up psyco.
Man, this is the highest density of crap in the same paragraph I have ever read in
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
It has been said many times before, but it's worth reiterating: [nearly] all of those wonderful runtime environments, and interpreters are written in C. Sometimes, language designers try to implement a self-hosting interpreter (like, say, scheme in scheme, ...), but even here, it still has to be bootstrapped somehow. Unless you want to do this in (unportable) asm, you still need C.
cpghost at Cordula's Web.
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.
Way to completely miss the point of language independence.
I am very small, utmostly microscopic.
C++ is perfectly portable if you don't use platform dependent libraries. You seem to be blaming the language because people develop platform dependent stuff for it! If your goal is to port stuff to another platform then obviously you start off with that in mind.
There's plenty of platform dependent Java code out there, or stuff that doesn't port properly.
In this world nothing is certain but death, taxes and flawed car analogies.
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?
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
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.
-Tom
Having seen side by side comparisons of J#, C# & VB running on
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.
Free Mac Mini Yeah, it's
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.
.NET app? [Ruby was on my mind]
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.
Check out LLVM: http://llvm.cs.uiuc.edu/
:)
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
would you rather program against the pitiful number API's that come with C#
.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.
Completely ignoring the fact that no APIs could "come with" C# because C# is just a one of many languages that compiles to
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.
Well, they are cross-platform if you are writing a cross-platform application, and they are not cross-platform if you don't.
Furthermore, the kind of cross-platform compatibility people primarily worry about with C++ is for libraries: it is things like regexp libraries or XML libraries that are going to be reused across platforms; GUI and I/O parts of applications are best developed in a platform-specific manner.
Or they have to be extended with platform spesific code.
For some reason, Java marketing has created the notion that cross-platform development matters a great deal, but that is nonsense. Cross-platform development (and sandboxing) matters for browser applets, a market that Java has largely ceded to Flash. For desktop applications and server-side applications, cross-platform applications don't matter at all.
Writing in a cross-platform toolkit and adding a small amount of platform-specific code is actually far superior to the 100% cross-platform approach: it is nearly as easy to port the application between platforms, but the application becomes enormously more usable by following platform-specific conventions and offering platform-specific functionality.
What it comes down to is that C++ is a better language than Java for cross-platform development. C# may eventually supplant C++ in that regard, because C# is simpler and safer, but still offers C++'s access to platform-specific features. But Java's religious insistence on what they incorrectly call "cross-platform" support actually is counterproductive.
I've been reading through this post and one thing irritates me. Everyone is acting like C has no garbage collection facilities. While garbage collection is not built into the language, there are several garbage collection libraries that can be linked into C. In fact, most of them merely replace malloc with some garbage collection code and replace free with a do-nothing routine. Linking the garbage collection libraries into the C code automagically sets up garbage collection and will allow you to recompile existing code with garbage collection enabled. Here's a sample library (first result searching 'garbage collector c' in Google):
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Nothing is static. That was my complaint about the standard C library. It is static... stagnant... showing its age.
.NET fixes many of those warts.
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!
- I don't need to go outside, my CRT tan'll do me just fine.
C++ is very portable if you choose compilers and libraries that are standards compliant and portable, which is now easy.
VC 7.1 (finally), GCC 3.2, the new Intel compiler - these are all very compliant with the standard. And remember that GCC, though not yet well optimized, runs almost everywhere.
The C++ Standard Library, the boost libraries, wxWindows, Qt, + 100 other libraries are all cross-platform.
Now compare this to the huge amount of work required to 'port' #develop from Windows to Mono.
All that's missing with C++ is a processor independent intermediate code, and that's coming in GCC 4. It's called LLVM.
Tom.
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 [samag.com] in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin [amazingkreskin.com] 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
Sigs? We don't need no stinking sigs!
0. "I assumed he was referring to the x86 platform"... see #4, below. ... c#. And it compiles itself. Take a look and you'll see what I am talking about. ...); .NET bytecode (like IKVM does) you did *not* lose the point of Java. you just translated your abstractions to another platform.
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
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
The actual "C" language may be declining in use. However, every single one of the "replacement" languages I've seen mentioned are simply "[subjectively] improved" modifications of C. Personally, I rarely use the higher level versions of C like C# or Java, because my line of work requires me to interface with OpenGL and do very CPU intensive calculations. Pointer math is absolutely required to effectively utilize OpenGL's more advanced extensions such as vertex buffer objects. And you can just forget about optimizing your vector math for CPU vectorization and parallelization, etc... in languages like Java or C#. This is not to say, however, Java and C# do not have their own benefits. When you need to write a small application (perhaps a frontend, or what not) and performance is not important, it's often faster to develop them in a higher level language. It's another instance of "the right tool for the right job". But the low level versions of C won't be dying for a very long time, because there will always be a need for portable, high performance APIs. The APIs that your high level C languages may interface with to perform tasks you simply can't practically accomplish otherwise. And of course the actual system kernel that everything runs would never be practical in a high level language.
What are you talking about?
Unsafe pointers are for the kernel to use, not userspace apps. Its okay if the kernel can crash the system, not if userspace apps can do so. Userspace apps cannot use unsafe pointers.
You don't switch between static and dynamic typing. Rather, you have dynamic typing, and optionally add type declarations in places where you want to tighten the interface or improve performance. There will be some runtime type checks, but modern compiler analysis can eliminate most of those checks. And what's wrong with type inferencing in your kernel? Type inferencing all happens at compile-time!
And the "raw core" they're talking about is not a low-level, close-to-hardware core, but a conceptually primitive core. The idea is that there is a simple base language to which both high and low level features can be added.
Strictly, Crush will have more overhead than C. However, given a good compiler, and well-written, straight-forward code, it is possible to achieve close to C performance for high-level languages like Crush. In some cases (things like generic data structures, where specializations can be used) performance can be even better.
Also note that while a kernel written in Crush might be 10-20% slower in raw performance, it makes up for it in other ways. For example, system calls won't have a huge overhead (hundreds of clock cycles on most modern kernels). Data doesn't keep having to be copied around. You don't have to put things like the X server in a seperate process to provide protection.
A deep unwavering belief is a sure sign you're missing something...
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
C vs. C++
The case for the continued existence of C is tenuous at best.
But it ain't happening any time soon. Nevertheless: D, anybody?
~metal_llama out.
---
move every sig!