Is C dead?

http://freeshells.ch/~revence/no-c.txt

Your thoughts on the above?

Yes.

C isnt dead, but it might well be dying. ESR has come out against it and said he doesnt use it for his day to day tasks anymore, which is significant because he was at one time a massive c-fag.

I personally do not believe that C is dead. There still is a need for a rather low level language, but it is loosing to C++ (the less OO part). The thing is that it is a tool and there are other tools available, use the proper tool for the job and C is not the proper tool for all jobs. If it comes to raw processing, think physics or numerics kernel, yes C is the way to go (not FORTRAN, mind you). But for rapidly develop the easy thing that tend to change, like business logic, don't mangle with such a hunk of language.

>>4
C can't do low-level well enough anymore, because it's all about speed on a single processor, and for physics and numbers, the article raises a significant point - why not use Assembly? It's that tiny bit quicker, which is probably what you're going for if you're using C.

>>1
All modern OS kernels are written in C, and C is still a huge competitor in embedded systems (though the obvious competitors, .NET CE and Java are gaining ground pretty fast). I don't think the former will change anytime soon.

>>3
rpm -e libcomerr2

>>5
There's a C->Fortran compiler that will let you continue to write in C, but also have your programs automatically parallelize.

>>8
Would it not make more sense to develop a new kernel-level language, free of the need to compile to ANOTHER language? The GNU could take up the call, instead of wasting time on Hurd.

>>5

Hold the phone. Just to put you back on track, C if not programmed by a total monkey is as fast as assembly and may be even faster in some cases where a grater level of optimization can be done.

When I am talking of numerics I am thinking of supercomputers. Yes, it only runs one program per processor, but at 99.99% of the CPU load for days and something around 100 programs linked together via MPI or similar. Try to match that with CLI, Java or Python in terms of performance.

Assembly drops out of the scale because the gain of performance (not always true) is degraded by the maintainability. C (more often C++ nowadays) is has about the same maintainability as Java, Python or any other 3. generation language. They differ only in small aspects, whereas assembly is an order of a magnitude. Not to think of independence of the processor.

>>10
Replace Assembly with Machine Code and you get the same argument, just better expressed.

>>3
>ESR
The one thing ESR is good for these days is to serve as a character in the webcomic Everybody loves Eric Raymond.

I'd trust the opinion of any random Anon over ESR's.

>>11

Thanks for the nitpicking. But yea, your are right. Though actually I was thinking Assembler Code. The ADD, JMP and RET, not the 0010010100101101010010010101001001...

>This insistence on speed is just silly and misplaced in 2007.

I stopped reading there. Whoever wrote that crap still thinks processors are getting faster exponentially. In terms of processor speed, we're actually beginning to LEVEL OFF.

Same with RAM. It won't be long before memory reaches its limits and we'll be wondering why the hell our 'Hello world' programs need a hundred gigabytes.

Speed is an issue if you are running numeric simulations. There is a difference if your simulation runs 14 days or only 11. Or for gamers, 20 FPS or 60 FPS...  There is still a legitimate use for C.

On the other hand most applications, think you average GUI based application, maintenance and development time (time to market for the businessfags) is paramount. C is inappropriate there.

C is not dead, there are only better tools for certain problem domains.

>>15
Not just in numerics, speed is an issue if you're writing kernel level control (lol scheduler, etc). If your OS isn't fast, then you're shit out of luck.

>>16 Any your <insert tool here> VM would just suck ass if implemented not in a efficient and fast way. Many applications have the luxury of waiting 90% of the time for user I/O, but your game would suck bad time if written in, say javascript...

>>17
unless your someone from sun or apple, who thinks java is all that.

ITT insane people who can't get over the fact that all important applications in use today are written in C.

GB2 your toy language, it's cool, not everybody is skilled enough for low level programming.

>>19
No trolls please. This is like, the one serious thread in /prog/

>>20
You are, like, um, totally, a troll, man.

>>20
Fact: every moron can write programs in toy languages because they require no knowledge and hide all the messy details from you idiots

Toy language faggots are in the same league as PHP "programmers"

>>22
1. List all toy languages.
2. Provide justification.
3. ???
4. GTFO.

PROTIP: you can get more work done in toy languages because you don't need to worry about messy details.

>>24
toy languages like Iota, Jot, brainfuck and python?

>>24
Exactly, they're tools for nubs who "don't wanna" know how computers work and just want to write 10 PRINT "LOL I CAN PROGRAM" 20 GOTO 10

In other words, not EXPERT PROGRAMMERS

Best thing is, they come here to defend that viewpoint. Just like an MBA who's in charge of a department of software developers might argue that he "doesn't need to know all that technical stuff" and then wonders why all his projects go down the shitter.

>>25
Can you not provide any justification for why they're terrible?

C won't die, it lasted a good 30 years.

Besides, those who say "people use C because of speed, but computers are getting faster and capacity of memory are getting larger" are pathetic. As hardware becomes better, what people demand of software will too.

Small Java apps that is easy to maintain, or a small servlet or applet that interface with a user, handling small amount of input is fine. But when you try to make it run a massive parallel system, it will fail, badly.

Most toy language's implementation... look at it? Does it not have the same "memory" problem which people like to argue as C? I mean, down to the lowest level, it's probably utilizing someone's C or assembly code. It's not anymore different to use someone elses memory management functions (OS) than say using Java's own gc since in the end it's the same thing provided whoever wrote them is experienced enough.

C just gives the responsibility to the programmer, rather than taking someone else's code and reuse it. Which I admit, is a good idea when you're working, when you're learning, it's not so much a good idea.

How about a new architecture? New ISA? PHP "Programmers" would have no fucking clue how to port their apps, instead they will rely on other REAL PROGRAMMER's implemetation to do their job. Atleast with C or asm, you have a working knowledge of the internals of the machine so learning a new architecture becomes easier.

tl,dr; the guy who wrote that is a fucktard that needs to stay away from the processor

>>27
They don't allow easy access to low level stuff or for that matter any common library (which are all written in C)

>>28
The point is that the programmer doesn't have to reinvent the wheel just to do something as basic like string manipulation and memory management.

It's just too easy to fuck things up when it comes to things like that and there's no gain unless what you're doing is extremely low level.

>>30
But because a programmer will have to re-invent the wheels whenever a new piece of hardware comes along, C won't die. It can't.

Unless some other, better, high low-level language comes along and is both as efficient and descriptive (or more so) than C, and people decide to slowly change over. Which I don't see happening within the next decade, unless some crazy new hardware springs about and there's a completely different hardware paradigm or something (quantum computing? lol, rite.)

Hay guyz, I heard NVidia is going to write their next gen drivers in Haskell.

C is so dead.

>>31
Keyword: LOW LEVEL

C will never die. We need it for drivers, embebbed applications, kernels, applications strongly CPU bound, etc, etc.

The issue here is that people use C for applications where it's currently pointless to use C, like I/O bound applications. They waste more time fixing bugs and get the same results.

I use C because it's a nice clean language.
I learned C after learning C++, so maybe that's influenced my opinion of it, C++ is a horrible mess.

>>33
Well, low level is where the Real Programmers work. Writing some shitprogram to calculate factorials in Haskell is something for a college freshman.

FUNCTIONAL PROGRAMMING IS STUPID.
IT'S NOTHING BUT A BUILT IN IF STATEMENT.
YOU HASKELL FAGS NEED TO SHUT THE FUCK UP.
OH, AND SOON ENOUGH C COMPILERS WILL AUTOPARALELLIZE AND DO THAT STUPID LAZY EVALUATION SHIT YOU HASKELLFAGFUCKS SEEM TO LIKE SO MUCH.
GB/2 "OMG I CAN'T KEEP TRACK OF MY MALLOC'S" LAND

C isn't going anywhere soon, but it is in decline. Why?

Writing an entire program in C is a case of premature optimization. Unless you're writing for some unusual case, what you want is a good language with a good FFI, so you can rewrite the hotspots in C and/or assembly. That gets you most of the speed for very little effort.

Unfortunately, most higher-level languages have the shittiest FFIs imaginable, especially the more popular ones.

http://www.prizerebel.com/index.php?r=51791

>>28
read the last two paragraphs, obviously you just went tl;dr

I'll restructure the sentence a bit:

C just gives the responsibility to the programmer, rather than taking someone else's code and reuse it. Which I admit, reusing code is a good idea when you're working, when you're learning, it's not so much a good idea.

How about a new architecture? New ISA? PHP "Programmers" would have no fucking clue how to port their apps, instead they will rely on other REAL PROGRAMMER's implemetation to do their job. Atleast with C or asm, you have a working knowledge of the internals of the machine so learning a new architecture becomes easier. How would a person that only studied high level abstract concepts know how to program the new machine? Doesn't matter what level of abstraction you have, it's a machine, in the very end, it's still a machine, just because you cover it with something fancy doesn't mean things can't go wrong. Although the last bit is the engineer's problem, not ours.

also:
string manipulation and memory management? thats always the fucking excuse some idiot that writes java for a living come up with. C/C++ STANDARD LIBRARY! when you're learning its always good to write your own functions. Memory management, heh, you should be glad you dont have to maintain a memory map since the OPERATING SYSTEM is doing that

DO YOU HAVE TO MAP THE ENTIRE RANGE OF RAM IN YOUR C PROGRAM?
DO YOU HAVE TO DEFRAGMENT THE CHUNKS IN YOUR C PROGRAM?
DO YOU HAVE TO MOVE AND COPY CHUNKS IN YOUR C PROGRAM?
DO YOU HAVE TO MANAGE OTHER APPLICATION'S STACK AND HEAP IN YOUR C PROGRAM?
DO YOU HAVE TO MAKE SURE THE RIGHT AMOUNT OF MEMORY IS PHYSICALLY AVALIABLE IN YOUR C PROGRAM?
DO YOU HAVE TO MANAGE VIRTUAL MEMORY IN YOUR C PROGRAM?

no offcourse, so stop bitching

>>35
same here

C IS DEAD.

COBOL IS THE FUTURE.