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."
FOR THE LAST TIME... (Score:4, Insightful)
Er.. (Score:5, Insightful)
Keep it real... (Score:5, Insightful)
Now what a spin. The
Punch Cards (Score:5, Insightful)
FORTRAN and COBOL are still in wide use, even if they aren't as popular as they once were.
Comment removed (Score:5, Insightful)
Declaring "X is dead" is just a cheap shot. (Score:5, Insightful)
,"Apple is dead". [macobserver.com]
When technologies really do die, its when noone gives a damn about them, and so noone will be writing a story about it.
Re:Adaption, but.. (Score:3, Insightful)
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.
Re:What about C++? (Score:3, Insightful)
Right tool for the right situation. (Score:2, Insightful)
Just because you can hammer in a screw if you try hard enough doesn't mean the screw driver is dead.
Re:So... (Score:5, Insightful)
Re:So... (Score:3, Insightful)
Re:What about C++? (Score:5, Insightful)
Re:Keep it real... (Score:5, Insightful)
I'm not sure or clear of why one would want to code in C instead of C# when developing for a
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
Saying C will be killed by a runtime architecture (Score:5, Insightful)
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.)
Re:Let it die! (Score:2, Insightful)
Re:Adaption, but.. (Score:5, Insightful)
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
Why C needs help (Score:5, Insightful)
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.
Please stop C++ calling portable (Score:5, Insightful)
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...
Not that simple (Score:5, Insightful)
Re:So... (Score:5, Insightful)
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.
Re:It's Dead Jim (Score:1, Insightful)
Nope, assembly is the best langage for that purpose (i.e. 0 difference between your language and the machine instructions). Programming languages exist to abstract away from the details of the hardware. This allows you to write less buggy, more portable code that can be compiled to run efficiently on lots of different architectures. C code will never run efficiently on, say, a massively parallel computer, but Haskell code might because its semantics aren't tied to a particular machine model.
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.
Sure you do. It's a mistake to think that programming languages which have PDP-11 oriented semantics and weak typing are giving you more "power" or "control". Power comes from modular code and well-designed algorithms, and control comes from a language which supports these things by abstracting away from irrelavent hardware issues. Why should I have to think about pointers to iterate through an array? Why should I have to write my own buggy and inefficient memory management code when it could all be done by a finely tuned and heavily tested GC?
C is not even the only language you can use for writing low-level code. Operating systems have been written in Lisp, for example. Nor is it the only language which compiles to efficient machine code: ML, Lisp, etc. can all run at comparable speeds.
c++ (Score:2, Insightful)
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.
Re:Let it die! (Score:2, Insightful)
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'
Re:What about C++? (Score:1, Insightful)
Re:Embedded/Real-time systems still need C (Score:3, Insightful)
[1] as long as you disable exceptions & RTTI and stay away from virtual/multiple inheritance & pointers to member functions.
Re:FOR THE LAST TIME... (Score:5, Insightful)
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
Re:Bug submission from banned contributor. (Score:1, Insightful)
Computer languages form an ecosystem (Score:5, Insightful)
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 [spinellis.gr]
- Examine the availability of 4500 URLs cited in computer science research papers. [spinellis.gr]
- To create the diagrams and the index [spinellis.gr] for my book Code Reading: The Open Source Perspective [spinellis.gr].
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 [freebsd.org].
- The socketpipe zero-overhead network pipe tool [spinellis.gr].
- The Outwit Windows-Unix shell integration tool suite [spinellis.gr].
- The fileprune backup file prune utility [spinellis.gr].
- A device driver for interfacing with my home's alarm system [spinellis.gr].
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"
popularity (Score:3, Insightful)
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
Re:Let it die! (Score:3, Insightful)
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.
The real question (Score:3, Insightful)
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.
Re:C's not dead because nothing better.... (Score:5, Insightful)
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.
pitiful number API's (Score:3, Insightful)
Re:It's Dead Jim (Score:5, Insightful)
Well, DUH. In the end its just ones and zeroes no matter what language you use. OO does not change the way computers operate much, it is a way to help programmers think about the problem domain in a way that hopefully is a bit easier for most of us. Jeez.
If you don't like it because it cramps your "bursting with geek studliness" style, that's fine. But if you don't even understand what high level languages are for, I doubt you know what you are doing.
Re:Keep it real... (Score:3, Insightful)
Languages don't die (Score:5, Insightful)
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.
Re:So... (Score:1, Insightful)
C is often chosen because it is the least of many possible evils, not because it is ideal.
Unless you choose something which really tries abstracting away from the underlying machine, like LISP or Mathematica, you're not making great leaps and bounds in moving from one language to another anyway. But many problems are so trivial (in the mathematical sense) that they're not worth the programmer's effort in coming to terms with the new paradigms[tm].
Re:Bug submission from banned contributor. (Score:1, Insightful)
No, bug reports aren't harassment, but I'll tell you what is. Proposing something new, and totally irrelevent to the DotGNU project (as per its stated goals and mission) every ten seconds, then not writing ANY of the code yourself, and finally bitching constantly about none of the DotGNU hackers dropping everything to implement your umpteenth million off the wall idea, is most definitely harassment. You harassed Rhys so much he almost left the project completely just so he wouldn't have to deal with you anymore. It's no wonder he didn't want to deal with your bug reports, no matter how valid they may have been.
By the way, you forgot to mention that you were unbanned from the project. You forgot to mention that, as a result, the ban on you in the #dotgnu irc channel was lifted. You forgot to mention that as soon as you learned of this you joined and then proceeded to spam the #dotgnu channel. Next time why don't you try telling all these nice
Rich
Re:Keep it real... (Score:4, Insightful)
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.
Importance of compiling C to portable executables (Score:5, Insightful)
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 [dotgnu.org], 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.
What type of documentation? (Score:3, Insightful)
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++.
Re:So... (Score:3, Insightful)
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.
Re:What about C++? (Score:3, Insightful)
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 (compared to Java, anyway), but to me, it's basically what C++ should've been. The only real "downside" in my opinion has been that it doesn't have class-local storage, but instead uses the exact same storage as C, which can make tracking data "globally" through an application slightly difficult, since you're either forced with global storage, or function-local storage (and then passing it around through everything via pointers), or some other more "traditional" means of throwing data about. C++ is nice that it's compatible with C libraries in general, and you can keep functions and data together in classes, which makes a decent amount of sense, though I've been told that the way C# does some of the more "trivial" data types (bools, attributes, etc) is a little more efficient relating to class storage.
But...here I am going on and on, too.
Poor Perspective (Score:3, Insightful)
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.
"the pitiful number API's that come with C#" (Score:4, Insightful)
Re:What about C++? (Score:2, Insightful)
Language != Libraries (Score:2, Insightful)
There's plenty of platform dependent Java code out there, or stuff that doesn't port properly.
Re:What about C++? (Score:3, Insightful)
I cannot believe this tripe is modded as 'insightful'. What ignorant rubbish (both the comment and the moderation of it).
It is relatively easy (as easy as with C) to create bindings for C++. And even if it wasn't, you can create C bindings for C++, so you could simply then create the bindings for other languages using the C layer.
This is a weird one (Score:5, Insightful)
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.
Re:Please stop C++ calling portable (Score:2, Insightful)
The point? (Score:4, Insightful)
Having seen side by side comparisons of J#, C# & VB running on
Re:Embedded/Real-time systems still need C (Score:2, Insightful)
Re:What about C++? (Score:1, Insightful)
Obj-C on the other hand looks like the designers thought to hell with C , we'll design our own new-look language and shoehorn it kicking and screaming
into C. Embedded SQL aside I've never seen such an ugly kludge of a language in my 15 years of working in the computer industry.
Please stop JAVA calling portable (Score:3, Insightful)
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:2, Insightful)
Re:What about C++? (Score:2, Insightful)
cross platform libraries (Score:2, Insightful)
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.
Re:What about C++? (Score:4, Insightful)
As classes are first class objects, I love it. However since its only used on Macs, I cry.
Re:Please stop JAVA calling portable (Score:1, Insightful)
Java tries to be cross-platform and it does so by having the virtual machine between the processor and the programs. C++ tries to be cross-platform in a different way. It gives you the ability to write semantically equivalent code for different processors without the need for a huge runtime (yes, C++ does have a small runtime).
C++ suffers from the trying to please everyone disease which is why so much is implementation dependant. C++ also suffers from lack of support from vendors. If I wrote a Java compiler that did not support all of Java (at some revision) it probably wouldn't be called a Java compiler. By the same reasoning I could call all C++ compilers that don't support the whole C++ standard non-C++ compilers. My point is that language support in compilers should not used as a reason to say a language is not portable. It would be same as Java claiming to be cross-platform and then having only a JVM for Sparc processors... Not very cross-platform due to a lack of support...
Re:FOR THE LAST TIME... (Score:2, Insightful)
If i need to develop applications fast, flexible, and portable, I will use an interpreted language, like c#, java, or (if i am a masochist
On the other hand, if i am coding in a microcontroller, coding OS level stuff, or coding extremely demanding software (i.e. massive simulations), I would choose C, as it gives me a chance to really monitor whats going on in terms of memory, and eliminates the overhead of the interpreter (and chances are i am not so concerned with code reuse).
Using C in the
Re:What about C++? (Score:4, Insightful)
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.
C is "dying", being killed by... C (Score:2, Insightful)
Re:couldn't resist (Score:2, Insightful)
Umm Doesn't that Linus guy write his little project thing in C ?
what is it called again ?
Re:You Sound Like (Score:3, Insightful)
I bet you don't like seatbelts (only poor drivers need them!) or hospitals (just for people who are careless and don't look after themselves!) either.
Re:Crush Scares Me (Score:3, Insightful)
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.