Why C Is Obsolete

http://www.softdevtube.com/2011/12/27/why-c-is-obsolete/#.TvsbHrIzPSI.hackernews

by nebiros • 15 years ago

35 72 15 years ago

softdevtube.com

jgw• 15 years ago

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

_genova• 15 years ago

What about Operating System?

dextorious8• 15 years ago

What about it? There are several OSs written in C++. BeOS was one.

lysol• 15 years ago

I think he's a little biased.

afroisalreadyin• 15 years ago

"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. "

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.

demallien• 15 years ago

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.

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

and compile with the C++ compiler.

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

Of course, care would need to be taken to not needlessly drag in the C++ runtime if it is not used.

nickolai• 15 years ago

I don't understand his matrix example.

in C++, you'd have a Matrix class with a getter. To get an element of the matrix you'd do

  int v = pMatrix->get(i,j);

whereas in C you'd typedef a Matrix structure type and have an accessor function

  int v = matrix_get(pMatrix,i,j);

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 this 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.

I dont see anything more than a syntactic difference here. The abstract reasoning behind the structures/classes is exactly the same.

C may be obsolete, but this is hardly a justification.

rmcclellan2• 15 years ago

I think the point he was trying to make is that a good language allows a library to be a "domain specific embedded language", in which an expert in some domain who is not an expert in the host language can do meaningful work. The matrix example is a particularly flattering one for C++, since a good matrix library in C++ will provide syntax that is quite close to the notation that one would use on paper for matrices.

jedbrown2• 15 years ago

The matrix example is a particularly flattering one for C++, since a good matrix library in C++ will provide syntax that is quite close to the notation that one would use on paper for matrices.

And it either (a) creates and destroys many intermediate structures or (b) templates everything by exposing the entire implementation to the user, resulting in slow compilation time and error messages that the domain expert couldn't hope to decipher.

cdavid• 15 years ago

I think the matrix example is particularly unflattering, and highlights the fundamental issues with the language. For once, there is no agreed-upon matrix library in C++, but many different ones. They are only "compatible" at a very low-level (a contiguous memory buffer), and the promises of performances often broken. The only one I know of that has been delivering on the performance front is eigen3, but I think the difficulty of the approach to become slightly ridiculous. When you need some "dynamic" optimization as done by eigen, C++ and templates are rather crude tools IMO.

astral303• 15 years ago

If you now wanted to have polymorphism, you'd have to do even more work in the function, which would probably involve looking up a function pointer in a table and invoking that (i.e. Linux VFS). If you didn't start out wanting polymorphism, but then wanted to add it, C++ is way less work to do it.

Why code this all by hand when the language can do it for you at no penalty? The only penalty I see in C++ for using classes or polymorphism is that it produces longer symbol names (w/ the type mangling)

You also get destructors that let you have convenient clean up of locally-allocated data (boost scoped_ptr), which helps make sure you don't leak memory/reduces bugs/reduced thinking required.

That's all possible without pulling out massive standard libraries or using slow-compiling/hard-to-diagnose template-based libraries (merits of those I leave undiscussed).

My biggest problem with C++ is a lack of a standard ABI (perhaps this has been addressed by know, it's been a while). C libraries are dead easy to link to. You know what you're getting. C++--not at all, unless you live entirely in the same compiler ecosystem.

One of the biggest perceived problems with C++ is that people start thinking: "well, now that I am using an OO language, it's time to write some classes!" Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.

If you're attempting your next project in C++, coming from C: only use those features of C++ that directly benefit you. Follow YAGNI. If most of your program is in flat procedures, alongside some objects, so be it.

Side rant: Consider that C++'s real uptake was in mid-90's, just as UML-ish diagrams began taking hold along with a massive rise of overdesign and no culture of agility. This led to massively overdesigned C++ apps. I'm sure the C developers were sitting there and wondering "Why the hell do I need all these classes? This used to be so much simpler." (I know I was.) Think about the horror that was J2EE--the same kind of thinking that led to J2EE also permeated C++ development at the time.

Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.

beagle33• 15 years ago

> Why code this all by hand when the language can do it for you at no penalty? The only penalty I see in C++ for using classes or polymorphism is that it produces longer symbol names (w/ the type mangling)

There are other penalties which people who write C++ are oblivious to. For example, switching the class of an established object in runtime:

Suppose you have two compatible class layouts (same field order and types, different methods). When you implement dispatch yourself, switching the behavior is a simple matter of replacing the vtbl pointer from one class to the other (I'm not sure Linux VFS does this, but it's common enough in C object systems).

Whereas if you use C++, the standard solution is to break this into a dataless "strategy" object (which can be changed independently of the data) and a data object which contains the state. If you never had the luxury of doing something like "if (obj->class == Living) obj->class = Zombie", you don't miss it, but it doesn't mean you're not missing out on some flexibility.

> Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.

Furthermore, just because you are doing object-oriented programming doesn't mean it is useful. (And a purist would say, just because you are doing programming, doesn't meant it is useful)

> Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.

I've switched to C++ in 1993 and back to C in 2004 when compile times with boost started to measure on a geological time scale and single error messages spilled onto my 2nd screen -- and haven't looked back. When a write GUIs, I do use FLTK which is C++ (very effective, but not idiomatic), because I haven't seen a GUI toolkit as good that's native C -- but other than that, I don't miss anything, and I'm not less productive.

C++, the language, has a lot of useful tools, but C++, the ecosystem, guarantees that in any nontrivial project you'll be thrown into the tarpit. In my experience, the overall effect of C++ on a project is negative. YMMV.

oneofthose2• 15 years ago

You can of course implement the same functionality using either C or C++. I agree - the two implementations would be very similar. But I don't think this is the point Bjarne is trying to make.

C++ challenges you to think in terms of types instead of functions. This is in my opinion often a more natural way to approach and solve problems and thus produces more elegant code. Because of that, C++ is a very powerful tool for library developers - you can design libraries that allow domain-specific developers to write expressive code that performs as if you had written more verbose C code. And this C++ code is not only more expressive for your fellow co-workers to read and understand but also in some cases for the compiler. This is the reason why C++ code can sometimes be compiled to faster machine code: you can give the compiler more information about what you actually try to accomplish (keyword: template meta-programming).

As with most things there is no definite answer. C code can be quite elegant and appropriate as well.

jedbrown2• 15 years ago

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.

dextorious8• 15 years ago

He means an actual Matrix interface, with operators and all, as opposed to a bunch of functions that just hide the arrays under the carpet.

divtxt2• 15 years ago

> 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++.

Thank the stars this didn't & won't happen!

Bjarne has been stuck in "C++ is the best & only language anyone needs" long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.

C occupies a sweet spot combination of:

- low-level with "no magic"

- small enough for most people to "hold in your head"

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.

zerostar072• 15 years ago

Then again, browsers are written in C++ and so are almost all GUI apps. We spend most of our time with software that is developed in C++, probably for a good reason

xyzzyz4• 15 years ago

so are almost all GUI apps

This claim is clearly false on Mac OS X and X Window platforms, and disputable on Windows, with the increasing share of .NET apps.

randombit2• 15 years ago

> when the only "magic" was basic virtual functions

What's "magic" about structs of function pointers? This is a classic idiom in C, just given a specialized syntax in C++.

bigfoot2• 15 years ago

With that argument you could invalidate any high-level language construct. They're all just "specialized syntax" of classic idioms in Assembly.

oneofthose2• 15 years ago

> long after the world has moved on to Java, C#, Python, Ruby, JavaScript, etc.

I don't think this is true for everyone. In fact I believe recently we have seen a renaissance of native code. C++ is the number one language for that. Those higher level languages waste a lot of cycles. You pay the warm and fuzzy feeling during development with performance and/or energy.

rbanffy3• 15 years ago

I used this argument for Java, but it's the same with C++.

If I can deliver a first version 2 months before the C++ version gets ready, I'll have two months to optimize market-tested algorithms before you hit the market. I may even have time to rewrite the sensitive parts in C.

If we are talking gadgets with embedded software, you may use a less powerful hardware and offer a cheaper product, but you'll have to amortize higher development costs and deal with a longer time to market.

For many things the world really moved on. C and C++ are still important, just not as important as they were a decade or two ago.

berkut3• 15 years ago

Here we go again...

C++ is used heavily from everything from Games, VFX programs (modellers, renderers/raytracer, compositors, paint programs), autopilot and control systems (cars, fighters (JSF), SpaceX are using it for their systems on their rockets), database systems, webservers, etc, etc.

There's a reason it is used a lot - in the real world it gets jobs done well by people who know what they're doing with it.

Saying "the world has moved on to Java, C#, etc, etc" is pushing it, given that the base system for many of those things are written in C++ (most of the native JNI stuff is C++, most Javascript compilers/interpreters are C++, many databases (Oracle, MySQL, MongoDB) are written in C++.

You may not like C++, and it might be difficult, and it may have worts, but thousands of people are using it very successfully for things no other language can do to the same degree overall.

divtxt2• 15 years ago

My bad - "the world has moved on" was too strong.

I meant something like: other languages have risen in popularity because they are better than C++ for many types of projects.

michaelfeathers• 15 years ago

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

bigfoot2• 15 years ago

I agree on Bjarne's opinion here -- it would be nice if C and C++ had merged at some point.

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.

peapicker• 15 years ago

"This also allows myths like C++ being too inefficient for embedded systems programming to live on in industry."

You just proved that it is too inefficient... too complex to efficiently implement dev tools for use with (some) embedded device's to-market development cycles in a timely fashion.

xxiao• 15 years ago

insane

g3orge• 15 years ago

it's not.

shreeshga• 15 years ago

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

kd0amg• 15 years ago

Everything but systems stuff should be a web app? I think some category of software is getting skipped here.

kabdib2• 15 years ago

C++ could have been so much . . . less.

Any language that takes the better part of a year to develop an adequate parser for is NOT to be trusted.

I had a long rant on RTTI, templates, the positively miserable experience around exceptions, and so on. But you've heard it before.

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.

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.

My experience with OS-level development is that you get a better code with vanilla C.

shin_lao2• 15 years ago

Every person uses a different subset of C++, but that subset varies from a group to the other. You cannot therefore "remove features from C++".

A lot of people use C++ to code as they would in Java or C#, generally their experience is terrible. Exceptions don't work the way you think they do (in C++ exceptions should be exceptional). Polymorphism is more verbose, it's not introspective, etc. There's much to say about it.

I've found you enjoy the language much more when you go generic/functional full speed. You also understand why some arcane features of the languages are there (such as the .* operator).

dextorious8• 15 years ago

"""Every person uses a different subset of C++, but that subset varies from a group to the other. You cannot therefore "remove features of C++""""

Actually you can. You don't remove them from the existing language that is, you make a better language with bs/redundant removed.

While "every person uses a different subset of C++" is true, it's not like everything someone uses is equally beneficial to have in a language. As the parent said, what is useful and what is not is not that controversial:

"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"

jetsnoc• 15 years ago

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."

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.

If you want to declare a language obsolete I recommend we discuss a language that is not in the top three!

wwweston• 15 years ago

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.

sc68cal• 15 years ago

That would be Objective-C

dextorious8• 15 years ago

I think he was being sarcastic...

nebiros• 15 years ago

and of course, everybody needs to know Linus Torvalds thoughts about C++: http://thread.gmane.org/gmane.comp.version-control.git/57643...

16s• 15 years ago

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.

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.

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.

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.

pouterspec• 15 years ago

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

xradionut• 15 years ago

The problem is C is "good enough" and C++ is "complex".

The only serious alternative system programming languages have been offered up by Niklaus Wirth and associates. Not much traction among developers...

swah• 15 years ago

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

epynonymous• 15 years ago

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.

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.

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.

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.

7GL would be where the software would have enough intelligence to figure out that it needs what features and have those implemented automatically.

mbq• 15 years ago

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.

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.

angersock• 15 years ago

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.

Instead, let's talk about things that C++ got right that aren't super obvious! :)

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.

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.

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.

What other cool things have you seen in C++ (or C)?

philluminati• 15 years ago

C is a beautiful language. I agree that with the assertion that it doesn't do abstraction. It only does two things:

* group code into functions * group primitives into structures.

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.

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.

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.

C++ is a federation of languages but writing pure C with gcc is better than g++ with all warnings enabled IMHO.

ec429• 15 years ago

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 like 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.

Of course, I'm atypical - when I'm not writing in C it's because I'm writing asm.

lelele• 15 years ago

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.

Long live C!

Why C Is Obsolete

Related Stories