Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why C Is Obsolete

softdevtube.com

Post reply on HN
Print view View original

11–20 of 75 posts

Re: Why C Is Obsolete

#11

Post by 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.

Re: Why C Is Obsolete

#13

Post by zerostar07 »

divtxt wrote: post #9

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

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

Re: Why C Is Obsolete

#14

Post by randombit »

divtxt wrote: post #9

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

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

Re: Why C Is Obsolete

#16

Post by bigfoot »

randombit wrote: post #14
divtxt wrote: post #9

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

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

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

Re: Why C Is Obsolete

#18

Post by rmcclellan »

nickolai wrote: post #7

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…

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.

Re: Why C Is Obsolete

#19

Post by jedbrown »

rmcclellan wrote: post #18
nickolai wrote: post #7

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…

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.

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.

Re: Why C Is Obsolete

#20

Post by astral303 »

nickolai wrote: post #7

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…

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.

Post reply on HN