Hacker News new | ask | show | jobs
by perdunov 4044 days ago
It seems that people are so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it.

So, although technically the existence of C doesn't make sense, as it is superseded by C++ (except couple of things), C is winning in the branding department.

6 comments

I don't know if this is the reason why people choose C over C++ for some projects, but if language complexity is the reason, it isn't that people are just "so intimidated by the infamous complexity of C++ that they don't even want to bother getting more familiar with it".

In the 90s, C++ was much more popular than it is now. It was used as the go-to general purpose language for all kinds of "serious" software (not addressed by VB or Delphi). Early on, almost everyone was very impressed with the power C++ brought, but after a few years, as codebases aged, it became immediately clear that maintaining C++ codebases is a nightmare. The software industry lost a lot of money, developers cried for a simpler, less clever language, and C++ (at least on the server side) was abandoned en-masse -- almost overnight -- in favor of Java, and on the desktop when MS started pushing .NET and C#. So while today C++ is servicing its smallish niche quite well, as a general-purpose programming language for the masses it actually proved to be an unmitigated disaster. It is most certainly not the case that C++'s infamous complexity is "intimidating"; C++'s complexity is infamous because of the heavy toll it took on the software industry. Which is why, to this day, a whole generation of developers tries to avoid another "C++ disaster", and you see debates on whether or not complex, clever languages like Scala are "the new C++" (meant as a pejorative) or not.

I also feel like a lot of people are biased because of Stallman and Torvald's stance on C++. I kind of have an irrational distaste towards the language, mostly due to their influence.
And Yosef Kreinin. Not arguing for or against the FQA, but its mere existence catalyzed (not fed) my journey of critical thinking towards C++.
and most of the people in coders at work, including

https://geeki.wordpress.com/2010/11/21/ken-thompson-on-c/

(when this topic comes up, I always find it funny that url's rarely contain ++ or # when talking about the descendants of C)

and apple of course, with their objective c.

I find funny that the by investing into JITs instead of optimizing compilers for Java and .NET, C++ managed to get a spot in HPC.

Now both Java and .NET eco-systems are getting there AOT optimizing compilers. .NET with MDIL and .NET Native, Java targeted for Java 10 (if it still goes to plan).

Also, thanks to Oracle's disregard by mobile platforms by not providing neither JIT nor AOT compilers for Java, C++ became the language to go for portable code across mobile OSes when performance matters.

> I find funny that the by investing into JITs instead of optimizing compilers for Java and .NET...

But that's because Java is meant to cover a very wide "middle" -- plus maybe a few corners where possible -- rather than every possible niche.

> Also, thanks to Oracle's disregard by mobile platforms by not providing neither JIT nor AOT compilers for Java

Well, it didn't start out that way, did it? But mobile platforms -- because they're rather tightly controlled -- are, and have always been, much more driven by politics than technical merit.

I am (or at least used to be, at some point) fluent in C++ and have built large applications with it. But I'd still rather write C, because its infamous simplicity is of a lot of use to me -- whereas I found that much of C++'s complexity tends to solve a lot of problems UML designers think we have, and very few problems that we actually have.
Not really. I'm sure this happens some of the time, but I suspect that's more common with developers who haven't written either.

In my experience, a lot of the developers who prefer C to C++ are developers who wrote a lot of C++, found that it only improved productivity in solving problems that it created, and went back to C and realized how much easier it is to write software in C.

C++ gets you caught up thinking about problems that don't even matter.

one of my favourite quotes from stroustrup says that 'don't use malloc and free, unless you want to debug 1980s' problems.

which i find curious, given the truism about debugging and understanding code taking longer than writing code.

personally i would prefer 1980s problems people in general know the answer to, rather than up to the minute esoterica.

all that said, the scott meyers modern c++ book is out, so i should really start and finish that before forming an worthy opinion in 2015.

I would recommend you to first read "Tour of C++" or another book that explains better the new features on C++11. Meyers explain very well some of edge cases of move semantics but if you don't understand the concept first then you might not have a good experience reading the book.

>"says that 'don't use malloc and free, unless you want to debug 1980s' problems."

The problem with malloc and free is that they left to the developer to keep track of the references and memory corruptions bug are not pleasant to debug. RAII idiom actually helps a lot in that context, and that is what Strouptrup was referring to.

thanks for the recommendation.

i think malloc and free are a lesser evil than this stuff:

http://thbecker.net/articles/rvalue_references/section_08.ht...

feel free to disagree!

The link that you provided does not have to do with malloc and/or free but with perfect forwarding:

http://thbecker.net/articles/rvalue_references/section_07.ht...

Also that example uses a Factory pattern which is actually verbosing the example, but it's like comparing apple and oranges since that's OOP which you actually wouldn't be doing in C.

What you would be comparing is something like:

mystruct * stcVar = malloc(sizeof(mystruct)); free (stcVar);

Vs.

std:shared_ptr<mystruct> stcVar;

Of course that is a stupid example; However things gets more interesting when you have pieces of code sharing the same structure (threads maybe?) and you don't know exactly which code should be the one in charge of releasing the pointer.

i think you misunderstand.

clearly, it is C++, not C.

instead of a simple malloc and free, you will invariably end down the rabbit hole learning about rvalues. perfect forwarding, move semantics, lvalues - the list goes on - these topics arise from the simple concept of RAII.

which i find worse than malloc and free.

The exietence of C makes perfect sense thanks, it's a relatively small and simple language with masses of flexibility.

C++ adds masses of complexity and implicit behaviour. While development in C++ can be quicker and might be 'safer' it can also produce all sorts of unexpected problems.

It also encourages all sorts of nested template types that can make existing codebases incredibly hard to read.

Further, in embedded situations, you may not have space for its standard library.

Even without the standard library, C++ offers lots of safety mechanisms over bare bones C.
And a lot of complexity, obfuscation and implicit behaviour.

I have developed and enjoyed developing in both. C has an elegant simplicity about it and you can do literally anything. C++ can be quicker, and it has a bunch of useful standard stuff, but it does have some downsides and quirks. There's room in the world for both.

I never enjoyed C as such, always felt too little when compared with Turbo Pascal, only used it in anger for university projects and my first job.

For anything else where the option was between C and C++, I always picked C++ when given liberty of choice.

I can learn complex stuff, but with C++ I don't C the point :) Honestly, I don't see what I'd buy with all that complexity.
> So, although technically the existence of C doesn't make sense, as it is superseded by C++ (except couple of things), C is winning in the branding department.

Programming Languages are in the domain of UX. Type systems, syntax, RAII -- they all just a serve a means to an end, which is useability.