Why C Is Obsolete

I don't understand his matrix example.<p>in C++, you'd have a Matrix class with a getter. To get an element of the matrix you'd do<p><pre><code> int v = pMatrix-&#62;get(i,j); </code></pre> whereas in C you'd typedef a Matrix structure type and have an accessor function<p><pre><code> int v = matrix_get(pMatrix,i,j); </code></pre> Looking inside the functions, they'do pretty much the same thing. In both of these functions you'd be basically accessing either element i+imax * j of your data array if you are implementing the matrix as a single array, or the j-th element of the i-th row if you were using a pointer to pointer structure. the C version would work on the provided matrix structire whereas the C++ would use the implicitly provided <i>this</i> structure. C++ would allow your matrix class to override some operator to make this look cooler - but operator overloading being a good thing is not really a consensus AFAIK.<p>I dont see anything more than a syntactic difference here. The abstract reasoning behind the structures/classes is exactly the same.<p>C may be obsolete, but this is hardly a justification.

<i>&#62; He explains that the languages should have been merged into one, so that C would have been a subset of C++ instead of nearly a subset of C++.</i><p>Thank the stars this didn't &#38; won't happen!<p>Bjarne has been stuck in <i>"C++ is the best &#38; only language anyone needs"</i> long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.<p>C occupies a sweet spot combination of:<p>- low-level with "no magic"<p>- small enough for most people to "hold in your head"<p>C++ matched these conditions for a brief time in it's life - the early 90s aka "Stroustrup 2nd edition" - when the only "magic" was basic virtual functions, and templates where just a promising experiment in an appendix.

I agree on Bjarne's opinion here -- it would be nice if C and C++ had merged at some point.<p>Unfortunately, the reason why this hasn't happened is inherent: C++ is so utterly complex (the C++11 standard contains more than 1300 pages of highly compressed language legalese) that especially in the embedded systems domain many vendors just don't have the time and resources to build a C++ compiler. And being caught in this vicious circle, embedded developers still aren't (and probably won't be for still quite some time) accustomed to programming at higher abstraction levels than what C offers. This also allows myths like C++ being too inefficient for embedded systems programming to live on in industry.

C++ could have been so much . . . less.<p>Any language that takes the better part of a year to develop an adequate parser for is NOT to be trusted.<p>I had a long rant on RTTI, templates, the positively miserable experience around exceptions, and so on. But you've heard it before.<p>C++ should have /started/ with a string class and a set of collection classes, rather than having them be bolted on a decade later. This would have driven the language in much more useful directions.<p>I don't know if it's possible to remove features, but I've seen three groups independently come up with essentially the same C++ coding guidelines (the Google C++ guidelines are a great example), all deprecating large swaths of the language because they are dangerous, fragile or make bugs.<p>My experience with OS-level development is that you get a better code with vanilla C.

I cannot access the article so I am only able to respond to the title at this time. I'm not a big fan of such sweeping generalizations. I am biased- I write in C all day long. C's basics are fairly easy to learn, it's an incredibly fast language and more than anything it is still in use! It may not be "elegant" nor mimic the style the author would prefer to write in but it certainly has a purpose and just because that purpose may not match his coding style that does not mean /everyone/ should jump ship and declare it as being "obsolete."<p>It is my basic belief there should be many tools in a developers toolbox and you should not always use the hammer on a screw or a very precise scalpel when trying to remove a sliver when a pair of tweezers will get the job done.<p>If you want to declare a language obsolete I recommend we discuss a language that is not in the top three!

"In this video, Bjarne Stroustrup explains why he thinks C is obsolete. He explains that the languages should have been merged into one, so that C would have been a subset of C++ instead of nearly a subset of C++. And then people could have used whatever parts of the C++ tool set they needed. "<p>Yeah right, a language/platform is a bag of fun toys out of which you can pick whichever ones you want, and all is well and everyone is happy. How can a programmer who has any experience claim something so ridiculous? When you decide on a platform, you have to live with whatever is there, the good and the bad. You can't tell people to use some feature but not touch this library, or not include that other package but write yours instead.

Bjarne knows damn well that you can have a Matrix interface in C instead of "an array and a whole bunch of arrays". This is not a new concept. I would have hoped he was above spreading such disinformation.

C is a beautiful language. I agree that with the assertion that it doesn't do abstraction. It only does two things:<p>* group code into functions * group primitives into structures.<p>However, it's simplicity is it's strength. You can write clean, standardised code in it. It's clean and simple. It's obvious. It's far too easy to make mistakes in C++ from bad type conversion or bad inheritance models (e.g. forgetting to virtualise something) to confusing subtly broken operator overloading that's counter-intutative.<p>C++ does render a C a little bit redundant. The abstractions it provides not only make programs more maintainable, but that additional intent allows compilers to potentially generate faster and more portable multithreaded code. We hit a point where C programs compile to faster/better assembly than a human can write. I expect that soon we'll hit a second wall where the C++ compilers can write faster/better multithreaded code than a C programmer could write or optimise and a C compiler couldn't support that directly "intent" as the language doesn't facilitate describing it.<p>However that point hasn't come yet. C still benefits from being clean, easy to interpret (from a human perspective) and is a demonstration of how to design a new language.<p>C++ is a federation of languages but writing pure C with gcc is better than g++ with all warnings enabled IMHO.

Grrrr, I dislike C++ - my current preference for a development environment is C with a scripting engine stuck on top, but I nevertheless have to agree with Bjarne on this one. There are enough libraries out there in C++ now that the pain point of having to write wrappers so that they are accesible from C needs to disappear.<p>It would be so easier if the only difference between compiling for C or C++ was whether or not symbols were mangled or not. Someone writing C code that nevertheless calls C++ code could still compile with the C compiler, instead of today's solution, specifically - wrap the file in #ifdef __cplusplus extern "C" { #endif<p>and compile with the C++ compiler.<p>Plus, no more need to deal with all of the different flags leading to CFLAGS, CPPFLAGS, CXXFLAGS, no more worrying if a bool is a bool or a _Bool etc etc etc<p>Of course, care would need to be taken to not needlessly drag in the C++ runtime if it is not used.

I think he's a little biased.

can't access the article for some reason, but i'm not sure if i agree with the title--there are still a shedload of fairly significant applications and software written in c (not c++): linux kernel, nginx, apache, etc.<p>c is still one of the most efficient languages out there next to assembly languages, you have complete control over memory management, most of the compilers produce highly optimized native code across multiple platforms, and there are a wealth of system level libraries to do some really significant things, i.e. it's as close as you can get to bare metal without having to deal with machine code.<p>i want to be clear here because i have been on both sides of the fence writing enterprise software in c as well as more recently in java, python, ruby, etc, so i know the advantages (and disadvantages) of OO versus a procedural language like c which i'm guessing is the major argument of the article. having libraries and frameworks like ruby on rails will significantly increase productivity and time for development, which in itself is a major win, but when you're talking about maximum performance, c is probably your best choice.<p>in general i think that writing software in the 21st century is still too complicated and error prone. if i want to write a web app, why do i still need to parse strings, perform database queries and such? why can't i have higher level abstractions or frameworks/libraries that give me this functionality. that's why i like django and rails, they seem to be moving in that direction (convention over configuration), though at the end of the day, you're still working with strings, arrays, and such. we should have software systems that provide even higher level abstractions than components and frameworks, for example, i want to create a social networking website that stores billions of 140 byte character messages, these messages should be searchable, this needs to run on iphone, chrome browser for windows, linux, etc. it would be great if the focus was on the features described like above and functionality rather than having to deal with SQL, arrays, strings, templates, css, ajax, etc. maybe the closest thing to this is like packaged software where everything is pretty standard and you customize only the portions that are necessary (maybe like twiki). i should never have to deal with SQL or even ActiveRecord (even though it's a nicer abstraction over SQL), all this logic should be taken care of for me, i should only have to define the high level stuff. when we get to that point, that's when i believe that we'll have achieved 6GL.<p>7GL would be where the software would have enough intelligence to figure out that it needs what features and have those implemented automatically.

To be fair, the interviewer used the provocative word "obsolete" when he asked the question. Dr. Stroustrup answered it honestly and use the words "merged" and "more compatible" and said there is no technical reason for the few existing differences today.<p>He also pointed out that he worked closely with the late dmr (office was just three doors down the hall) and still has strong ties to other famous and well-known C gurus (dinner with Brian Kernighan) and that C and C++ coexisted w/o issue in their world.<p>His final point was the best though... he pointed out how programmers argue and fight about which is better, not the designers and researchers themselves.<p>Edit: Also, the new C11 standard brings C closer to being a complete subset of C++ and subsequent standards will continue doing this until they are merged, but this won't make C obsolete.

It seems to me that what Bjarne likes about C++ over C is its provision of copious quantities of syntactic sugar - turning things that are perfectly expressible in C into supposedly more 'natural' formulations. I suppose if you <i>like</i> cancer of the semicolon, C++ may be the right place for you, but in my opinion if you really want abstraction you should be using lisp (the simple, unbound syntax makes every function you implement act like an extension of the core language), and otherwise you should use C.<p>Of course, I'm atypical - when I'm not writing in C it's because I'm writing asm.

I don't think C will be obsolete as long as it is hard to do C++-ish things in it.

The problem is C is "good enough" and C++ is "complex".<p>The only serious alternative system programming languages have been offered up by Niklaus Wirth and associates. Not much traction among developers...

If only there were some extension of C which added the ability to more easily work with abstractions (say, particularly, object-oriented abstractions) that was a strict superset of C.

Actually, after having used it for ten years, I think C++ is the language which should be deemed obsolete. We don't need such a complex language anymore.<p>Long live C!

I hate this superset/subset idea -- those are just different languages, with separate philosophies and totally incompatible practice sets. Merging is an equal madness as merging Haskell with Python.<p>On the other hand, from a fully practical view, even after omitting all incompatibilities a C code compiled with C++ compiler will be bloated with C++ standard lib, and will have screwed symbols.

C++ is a kludge. There should ideally be only two types of languages. System level: C Web-App Level: Python/Javascript/Java

Better not tell the embedded systems engineers, electronic engineers, os developers .....

I feel like starting a Movement in Defense of Small Languages.

So, all we're going to do is nerdrage about C vs. C++ here. There will be diehard architecture astronauts on the one side, and crufty neckbeards on the other. We've all seen this thread before.<p>~<p>Instead, let's talk about things that C++ got right that aren't super obvious! :)<p>For me, one of the coolest things about C++ is having destructors. The neat thing about them is that they are based on the scope of an object, and tie directly into when the object leaves scope in the language (as determined at compile time). Any code there gets run when the object is deleted or leaves scope, and this is guaranteed to happen immediately.<p>So, I know exactly when an object is no longer "needed", and if I'm careful I can use things like smart pointers and reference counting to guarantee that a shared resource gets removed when it needs to. I can also override new/delete and do some magic to have a reliable "hey, come free me from the heap later" behavior--when the destructor is called, have the class append itself to a list of things to be GC'ed when the time is right.<p>Java, for example, doesn't do this--a request to finalize may be fulfilled, one day, when the VM feels like it. This makes smart handling of things like system resources really clunky, and can force me to write C-ish code like freeSystemResources() or something. Having an ability to explicitly know when lexical scope has been left is pretty cool.<p>What other cool things have you seen in C++ (or C)?

and of course, everybody needs to know Linus Torvalds thoughts about C++: <a href="http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918" rel="nofollow">http://thread.gmane.org/gmane.comp.version-control.git/57643...</a>

insane

it's not.

What about Operating System?

C++ is as ridiculous as Bjarne's hair.