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)
Re:FOR THE LAST TIME... (Score:4, Funny)
couldn't resist (Score:4, Funny)
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
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
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:FOR THE LAST TIME... (Score:5, Funny)
I agree 100% that C is the biggest inspirator for new languages. One can only take being burned by C's shortcomings so much before deciding that there has to be a better way.
Re:FOR THE LAST TIME... (Score:3, Funny)
What about C++? (Score:4, Informative)
Re:What about C++? (Score:3, Insightful)
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.
Re:What about C++? (Score:5, Insightful)
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 an
Re:What about C++? (Score:4, Funny)
to drop an equation solver into your OO program.
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 (compar
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:What about C++? (Score:3, Funny)
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.
After meeting the designer, I'm inclined to agree.
Re:What about C++? (Score:3, Informative)
Re:What about C++? (Score:3, Informative)
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.
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...
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++.
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:3, Informative)
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
Re:What about C++? (Score:4, Informative)
I'm not very familiar with KDE's language binding availability right now, but I know that being written in C++ would make it more difficult to provide alternate bindings. C, being the lowest portable denomiator of programming languages is simple to create alternate bindings for.
language bindings Re:KDE, language support (Score:3, Informative)
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
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.
Er.. (Score:5, Insightful)
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!
Comment removed (Score:5, Funny)
Wow! (Score:4, Funny)
Can I get them to compile asm to java bytecode next?
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.
Not that simple (Score:5, Insightful)
Re:Not that simple (Score:5, Funny)
(it's a _joke_, laugh!)
Yup that exists (Score:5, Informative)
Re:Wow! (Score:5, Informative)
Takes compiled mips binaries and converts them to functional java classes.
Re:Wow! (Score:5, Informative)
You do know that the
One the app is running, the processor is dealing with native, optimised machine code rather than the IL bytecode.
Dan.
Re:Wow! (Score:3, Informative)
C# is not run as interpreted bytecode (which would be slow); it is "compiled" to bytecode and then, when the program is first run, compiled to native code. It is about 10-20% slower than a similar program written in C++, but for most GUI apps on modern machines, this does not matter.
Of course, for "real programmers", C and C++ still grant you much more power. Function pointers, inline assembly, easy bitwise operations... C# is fine for many programs, but just TRY to implement a network pro
Weren't you guys beaten to it by CNet? (Score:3, Funny)
Because there was no more room in hell? (Score:5, Funny)
Keep it real... (Score:5, Insightful)
Now what a spin. The
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
Re:Keep it real... (Score:3, Insightful)
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.
Comment removed (Score:5, Insightful)
Re:C's not dead because nothing better.... (Score:3, Informative)
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).
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.
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
Re:C's not dead because nothing better.... (Score:5, Informative)
Actually some of them that look like they're written in C are actually written in C++. They're just careful to make sure that all the public interfaces are extern "C". They can then use whatever fancy C++ features they want in implementing the library.
I think this is one of the real strengths of C: because the ABI is so simple, pretty much anything can link to C and almost anything can create C bindings.
Re:C's not dead because nothing better.... (Score:5, Informative)
Hardly.
One of the problem with modern languages is, you can't write an operating system in them.
Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project [sourceforge.net] for an OS written in a safe language.
One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code.
I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.
Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable.
Common Lisp [cons.org]
Another Common Lisp [sourceforge.net]
Ocaml [ocaml.org]
Scheme [inria.fr]
Dylan [gwydiondylan.org]
Another Dylan [functionalobjects.com]
We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.
Huh? (Score:3, Funny)
In the meantime I'll just risk being labeled "old-fashioned" and compile C straight to binary
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.
Insightful (Score:5, Interesting)
Broader Perspective (Score:5, Funny)
> 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 not dead. (Score:4, Funny)
Embedded/Real-time systems still need C (Score:5, Informative)
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.
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.
C is Dead (Score:5, Funny)
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.)
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:Didn't RTFA but have some questions anyway :) (Score:3, Informative)
- Pointer arithmetic
A: YES
- Hardcoded type sizes instead of using sizeof() (i.e. assuming sizeof(int) == 4)
A: WTF ?
- Lax rules for casting
A: YES
- And so on
A: Hey, porting glibc
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.
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
I would take C++ over Java/C# anytime (Score:5, Informative)
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?
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!
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
Re:C is alive, not becoz of Portable.Net (Score:4, Informative)
Forth? OpenBoot? The currently alive OpenBIOS project?
QED
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
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
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.
pitiful number API's (Score:3, Insightful)
Thank God! (Score:5, Funny)
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.
You Sound Like (Score:3, Informative)
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?
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.
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)
Java vs C vs C# (Score:5, Informative)
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. :)
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.
The point? (Score:4, Insightful)
Having seen side by side comparisons of J#, C# & VB running on
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
Pitiful number of APIs? (Score:3, Informative)
Completely ignoring the fact that no APIs could "come with" C# because C# is just a one of many languages that compiles to
Punch Cards (Score:5, Insightful)
FORTRAN and COBOL are still in wide use, even if they aren't as popular as they once were.
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: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
Re:So... (Score:4, Informative)
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.
Re:So... (Score:5, Informative)
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: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.
To be sure, check Google News. (Score:5, Funny)
However, you should check News.Google.com [google.com] frequently in case the world ended and no one told you.
Re:So... (Score:5, Insightful)
Re:So... (Score:3, Insightful)
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.
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 vulnerabili
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.