
Why C Is Obsolete - nebiros
http://www.softdevtube.com/2011/12/27/why-c-is-obsolete/#.TvsbHrIzPSI.hackernews
======
nickolai
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.

~~~
rmcclellan
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.

~~~
jedbrown
_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.

~~~
mattgreenrocks
It's almost as if everything has tradeoffs, and engineers have to make them
consciously!

Optimize when necessary. Until then, no need to mutilate expressiveness if the
language allows it.

------
divtxt
_> 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.

~~~
berkut
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.

~~~
divtxt
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.

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

------
kabdib
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_lao
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).

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

~~~
shin_lao
Perhaps I would understand better what you're trying to say if you were to
give me an example of a controversial feature.

~~~
kabdib
Multiple inheritance.

Operator overloading.

Doing non-atomic work in constructors (allocating memory, doing file I/O,
etc.).

RTTI

Template metaprogramming

... and more

------
jetsnoc
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!

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

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

~~~
dextorious
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.

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

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

------
lysol
I think he's a little biased.

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

------
16s
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.

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

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

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

------
wwweston
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
That would be Objective-C

~~~
dextorious
I think he was being sarcastic...

------
lelele
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!

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

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

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

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

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

------
angersock
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)?

------
nebiros
and of course, everybody needs to know Linus Torvalds thoughts about C++:
[http://thread.gmane.org/gmane.comp.version-
control.git/57643...](http://thread.gmane.org/gmane.comp.version-
control.git/57643/focus=57918)

------
xxiao
insane

------
g3orge
it's not.

------
_genova
What about Operating System?

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

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

