
Defective C++ - dsplatonov
http://yosefk.com/c++fqa/defective.html
======
Pacabel
It's pretty well known that C++ suffers from a variety of problems. Many of
them have been known about for some time. Despite this, nobody has been able
to produce a truly viable alternative.

There have been some encouraging developments, of course. But they've had
their own drawbacks that are often worse, in practice, than the problems of
C++.

D is an example of this. A lot of new and existing C++ code probably could be
written in D instead. But D lacks the widespread adoption and support that C++
offers. This translates into there being fewer third party libraries
available, which increases the burden on programmers to an extent that's
usually unjustifiable during commercial development And this, in turn, helps
prevent the adoption of D.

Rust is another example. It theoretically sounds like it could be a
replacement for C++, but that's only true in the far future. The language and
its standard libraries have yet to show any real signs of stability. We've
been hearing that there may be a 1.0 release at the end of 2014, but time is
quickly running out on this. Even then, it will merely be where D is at that
point. While there may be a fair number of Rust libraries in existence at this
point, many of them have become broken due to language or standard library
changes, many are woefully incomplete, and many are totally abandoned.

Then there are Java, C#, Go and others which claim to be successors or
potential replacements, and perhaps this is true in a very limited subset of
cases. But the remaining situations where they aren't suitable are large in
number and quite critical.

Furthermore, we are continually seeing C++ adapt and evolve. It's getting new
features and functionality that these competitors are offering, while still
usually giving far more freedom and control to programmers, far better
performance, far better portability, far greater practicality, and continued
use for serious new software projects. These factors combine to make it an
even more difficult situation for potential C++ replacements. They just may
not bring enough to the table to warrant replacing C++ for a majority of its
users or potential users.

~~~
loup-vaillant
You realize your criticism of D has nothing to do with the language itself,
and everything to do with network effects, and first-to-market effect? Of
course D lacks the widespread adoptions of C++, it's a newer language! The
same goes for your criticism of Rust.

If I were moved by these objections, I would conclude that we shouldn't even
try to overthrow established programming languages. Heck why not embrace
Status-quo Bias altogether?

About Java & co, you need to realized that most C++ code out there didn't need
C++ (or D, or Rust) in the first place. The projects that are (i) very
demanding to the CPU and memory, (ii) need a complex solution, and (iii) can't
possibly separate a few bottlenecks in C from a high level language with a
good FFI (Python, OCaml, Lua, Haskell, Lisp…), are uncommon. Some of those
projects have incredible _impact_ , but they are still uncommon.

Java & co are for projects where it was a mistake to use C++ in the first
place. They don't compete with C++ on its own turf, they just take away
territory C++ should never have controlled.

~~~
Pacabel
No, D's lack of adoption does involve the language itself to some degree.
While the core language itself is better than C++ in some ways, these benefits
just aren't compelling enough to exceed the downsides of D, nor do they
outweigh the benefits that C++ offers.

And D isn't a new language, by any means. It has been out there for well over
a decade now. That should be more than enough time for it to achieve
relatively widespread usage, were it to actually offer sufficient benefit over
C++ and its other competitors.

~~~
loup-vaillant
I don't know D, so I wouldn't know about it's downsides, besides the one you
have spoken of already: lack of adoption. What are the downsides of D that
wouldn't go away if it was widely adopted?

You say D is sufficiently old, that it's lack of adoption is significant
evidence that we should _never_ adopt it. The problem is, most people think
like you do: they wouldn't adopt a language before it has some visible
traction. The corollary is, new languages _never_ get widely adopted, unless
of course some Big Corporation does massive publicity around it (Java, C#…).
The real reason D isn't widely adopted, is not because it's not better than
C++. It's because it was not widely adopted in the first place. Textbook
chicken and egg.

You speak of benefits and downsides of a language, but what you are really
speaking of is the whole ecosystem as it is _now_. You don't even look at the
long term potential.

Also, put yourself in the shoes of a language designer. Say you have a
brilliant programming language. Experimental quantitative research has shown
with no ambiguity that your language is better than some established, old
language in its own niche (20% more productivity, 10% less post-release bugs,
same observed runtime speed and memory consumption…). Just one little problem:
your language have zero users, and only a little standard library. How would
you get people to adopt your new language?

Hint: people won't believe your peer-reviewed experiments. People will refuse
to learn a new syntax. People will want to reuse their old code. Even if you
come up with an automatic translation tool, people will not trust it. People
will say the benefits of the language are outmatched by the drawbacks of its
standard library (too small), and of its community (none to speak of). People
will be afraid of the required training (even if your research shows
productivity benefits after a couple weeks).

How do you fight Status-quo Bias?

Personally, I found only one answer, which unfortunately isn't applicable
everywhere: making the new language's implementation so cheap that all it's
costs are paid off in a single project. DSLs may do that: with the right
tools, a small external DSL can take no more than a couple hundred lines to
implement.

------
loup-vaillant
This page is about C++98. C++11 and 14, while making some important things
easier, have their own set of problems.

Which is why Yossi Kreinin called for help about updating the FQA for C++1x
and beyond. As he no longer works with C++, both his expertise and the time he
can waste on this language are dwindling. [http://yosefk.com/blog/c11-fqa-
anyone.html](http://yosefk.com/blog/c11-fqa-anyone.html)

~~~
fetbaffe
A good FQA and a great blog post summary.

 _And you can see the same shrewdness, the same "altruism", the same attention
to detail, the same tunnel vision – "this shit I'm working on is so important,
it deserves all of my mental energy AND the mental energy of my users at the
expense of caring about anything else" – throughout the C++ culture. From the
boost libraries to "Modern C++ Design" (the author has since repented and
moved to D – or did he repent?..) to the justifications for duplicate and
triplicate and still incomplete language features to your local C++ expert
carrying his crazy libraries and syntactic wrappers and tangling your entire
code base in his net._

So true.

In the beginning of my career, I too was drinking the C++ koolaid. I really
believed that manual memory management, large and convoluted class
hierarchies, obscure template programming, cryptic exception handling, and
pointer tinkering was necessary in a language and, of course, to get good
performance you had to use C++. What a complete lie.

I still meet programmers who believe that, because it is _important_. And then
you look at what kind of software they are writing, some desktop app or some
web service. Huh.

If you look where the C++ community ended up by C++ programming experience
over the years is that you should probably avoid all of that if you want bug
free code.

~~~
nly
> I really believed that manual memory management, large and convoluted class
> hierarchies, obscure template programming, cryptic exception handling, and
> pointer tinkering was necessary in a language and, of course, to get good
> performance you had to use C++. What a complete lie.

It was a complete lie. Fortunately, none of that stuff precludes you from
using C++.

~~~
fetbaffe
True, and when I need to use C++ today I use a small subset of it with some
new features from C++11. Namespaces, functions, structs, lambdas and smart
pointers is usually all I need.

The standard library has become so much better then the old days. Now I can
even create threads without extra libraries. Unfortunately std types are no
longer COW with C++11.

Now if I only can get rid of that awful header file I almost have something
that works without too much headache and profanity.

~~~
nly
> Unfortunately std types are no longer COW with C++11.

GNU std::string being CoW (still is atm btw) has always been deceitful. The
API was simply never designed for that implementation, which resulted in
seemingly cheap read-only operations (char x = str[42];) becoming quite
expensive.

I'm glad you mentioned actually, since API authors embracing reference
semantics through fear of overhead is a great rabbit hole of systemic
complexity for C++ developers who are then forced to swim against the tide in
the language. Sadly I don't think Rust goes far enough in bringing love to
value semantics.

~~~
fetbaffe
Ah, I did not know that. I mostly use CoW when I do Qt stuff to get a clean
API (but Qt gives you whole range of other annoyances). Qt data types works
well together with std lambdas without the need of smart pointers.

In what other language has so many Stack Overflow threads and blog post been
dedicated just how to pass a simple parameter to a function. And with C++11 we
have one more way of doing it. It is really mind-boggling.

I never have this problem in other languages and I can do equal the heavy
lifting.

And for the C++ programmer it gives a false sense of satisfaction when
spraying the code with const& everywhere. I _saved_ performance!

Just bizarre.

------
shin_lao
This FQA is often posted and you should know it's subjective and outdated. You
can read more about it here:

[http://stackoverflow.com/questions/3171647/errors-in-c-
fqa](http://stackoverflow.com/questions/3171647/errors-in-c-fqa)

~~~
loup-vaillant
And there: [http://www.yosefk.com/c++fqa/web-vs-
fqa.html](http://www.yosefk.com/c++fqa/web-vs-fqa.html)

As for the "subjective" part, it doesn't really weaken the argument of the
FQA. I estimate most of his "subjective" claims are subjectively true for most
programmers.

When something is subjectively true for a sufficiently large majority of the
relevant group of sentient beings, asserting its truth, period, is common
usage.

~~~
shin_lao
The FQA states that the C++ doesn't have garbage collection and presents that
as a problem. It's a non sequitur. It's like saying "I don't like this knife,
I cannot eat soup with it".

~~~
loup-vaillant
I agree with your non sequitur, but I think there is something there
nonetheless.

I think Yossi Kreinin's main objection is not the absence of garbage
collection in C++, but the fact that so many projects that could use garbage
collection, don't.

Like "I need performance!" No you don't. "I _really_ need performance!" My GC
is just as fast as your malloc/free. "I don't use malloc/free, I have my own
custom allocators, you ignorant Java programmer!" I just use manually managed
arrays for that, and enjoy garbage collection for the rest of my data. "My
environment can't afford me any GC pause!" My GC hardly pause, and it collects
gigabytes of data. "But I know things about my data your GC don't!" OK, _now_
you may have a point.

The performance difference between C++ and a well implemented native language
with garbage collection (OCaml, Haskell, Lisp, Go…) is not large. Definitely
less than an order of magnitude. Your constraints must be _real_ tight to
force you to give up garbage collection.

In the vast majority of projects, not using garbage collection is a problem.
If not with the language, at least with the community.

\---

I think Yossi Kreinin don't object the knife itself. He objects the fact that
people actually try to eat soup with that damn knife, spilling soup and
cutting their tongue in the process. Sometimes, we do need sharp edges (for
cutting meat). But for much eating activities, sharp edges are just a
hindrance.

------
silmar
While c++ has its share of annoyances, I fail to see the relevance of this
text, even more so in 2014, why do You repost it?

~~~
loup-vaillant
C++14 has a good share of the problems of C++98, while adding its own. It's
not like C++ ceased to be the most crazily complex and the most deadly trapped
language in widespread use.

I'll grant the FQA as such is outdated, but _irrelevant_? C++ was a huge
mistake to begin with, a giant waste of time at the global scale. (Things are
different at the individual scale, because network effects.) Having a heavily
documented case for the oblivion of C++ is a good thing.

