
Why C++ Is Not "Back" - jsonmez
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/
======
SomeCallMeTim
Portability _is_ still a good reason to use C++. If you want to be portable
between Android and iOS, for example. C# on either platform requires you to
ship an extra 10Mb of libraries, and (especially on older phones) adding C#
overhead on top of everything else just doesn't make sense.

I write games, mostly, so performance does matter to me, though I'm not trying
to squeeze "every last bit of performance" out of a chip. I just want some
parts of the code to be entirely predictable in performance. So C++ and OpenGL
are still my tools of choice. Been using C++ for years and would ace that set
of interview questions (except possibly the list of algorithms in
&lt;algorithms&gt;). And yet...I actually hate C++. It just happens to do the
job better than anything else.

And it also happens to interface really well to a REALLY good scripting
language, Lua.

To some degree I wonder why everyone focuses so much on Java or C#, when the
amount of overhead code you have to write is similar in both cases to C++. Yes
the languages are easier to understand, which is good, and they're often
wrapped in IDEs that make it easy enough a monkey can produce code that will
compile, but it still requires a lot of boilerplate to do just about anything.
More than C++ in some cases, though not always. So much that they make the
IDEs write a lot of boilerplate for you -- but the overhead is not only in
typing out the lines, but in screens and screens of code that distract you
from the actual problem you're trying to solve, and that you have to sift
through to find the code with the bug you're looking for.

So I stick with C++ for things that need speed, and I use Lua for things that
don't -- and I promise you that I can write just about anything in fewer
(legible) lines of code in Lua than it would take to do the equivalent in C#
or Java. And since # of bugs is proportional to the number of lines of code, I
end up way ahead.

~~~
seanmcdirmid
> Portability is still a good reason to use C++.

Quite true, thankfully WP8 supports native now. If portability is not a big
deal, I prefer C# and DirectX (via sharpDX). It's much less code than C++, and
just not as insane.

> And since # of bugs is proportional to the number of lines of code, I end up
> way ahead.

Can't tell if you are being serious here. That's just not true at all; it's
well known that LOC is a poor indicator of bug occurrence.

~~~
rymith
That's interesting, I've read several papers on a direct positive correlation
of LOC to # of bugs. Do you have any papers to back up that assertion that
there is no correlation. Common sense would dictate that the more places
humans can insert an error, the more errors will be inserted.

~~~
sp332
The papers I've seen show that bugs _per line of code_ go down as class size
increases, until about 200 lines of code. But since the code is larger, the
total number of bugs goes up in larger classes compared to smaller ones (as
you would expect). This might be used as an argument against refactoring code
into too-small classes, but I'm pretty sure total code length correlates with
total bugs. <http://news.ycombinator.com/item?id=3037293>

Edited to remove dumb generality.

~~~
seanmcdirmid
> I'm pretty sure the only way to minimize bugs is to write less code.

Please think about what you are saying. Such an overly broad statement is so
easy to shoot down, I'm sure there are plenty of other ways of minimizing
bugs. NASA and Boeing have this figured out, for example, although it is
incredibly expensive (formal verification, independent redundancy, extensive
testing, static analysis, etc...).

------
general_failure
Excellent write up.

I am a good C++ developer but my dislike for the language has grown ever since
c++11. Many parts of the language are arcane and unfortunately these parts are
used over and over again by many programmers either to show of their
'coolness' or because it's the only possible way.

Here try this for size: [https://github.com/boost-
lib/bind/blob/master/include/boost/...](https://github.com/boost-
lib/bind/blob/master/include/boost/bind/bind.hpp) (sorry if that blurb made
you blind)

I also dislike perl. A large amount of perl code contains shorcuts - like $^p
or %#p (not real perl patterns but I hope you get the point). These patterns
are ungooglable and hard to remember. The only people who know them are those
who have spent a lot amount of time with the language.

The result is code that is extremely hard to understand and read.

Languages must be optimized for reading and not writing. Of course, nobody is
asking one to go overboard (like COBOL) but reading a computer program should
not hurt the brain and should not require years of training.

This is why I will not advocate C++. I would advocate C, Python or JavaScript
(yeah javascript, it has it's pitfalls but it's very easy to master). There
are possibly other languages like Ruby but I haven't taken the time to learn
them.

(BTW, If you want to see how C++ could be done right, look at something Qt
from an API point of view).

~~~
fauigerzigerk
Yes, some of C++ is indeed arcane. But what sets C++ apart from other
mainstream languages like Java is that you can optimize for reading to a much
greater extent than with other mainstream languages like Java or JavaScript.
You can create entire DSLs all within the language. I'm not saying this is
always a good idea, but if you want to radically pioritize readability, C++ is
a better language than most.

Some of the boost libraries actually demonstrate this very well. If you look
at the implementation of the library, you may be intimidated by its complexity
(as you have shown with bind), but if you look at examples of its usage, you
will often find it a lot cleaner than other languages.

Imagine what you would have to do in Java in order to do what bind does:

    
    
      int diff(int a, int b) { return a - b; }
      auto reverse_diff = bind(diff, _2, _1);
      
      assert(diff(5, 2) == 3);
      assert(reverse_diff(5, 2) == -3);
    

(Obviously, this particular example is trivial in any dynamic language, but
that's a different debate)

I'm not saying C++ is the only or even the best language for creating
statically typed DSLs. But it is a language in which you can optimize for
readability in a much more radical fashion than in some other mainstream
languages.

~~~
pmr_
And now consider the confusion of your users when diff is picked up by ADL,
but reverse_diff isn't.

A lot of the code that tries to showcase new C++ features often falls short on
some of the intricacies of the language or doesn't embed it into a larger
scheme of a library. If my library offers customization via ADL across the
board that kind of coding goes right out the window.

I'm aware of the proposals to make function objects through ADL, but this is
but one example where the complexity of C++ comes to the surface.

~~~
fauigerzigerk
C++ is undoubtedly complex. I'm not a huge fan of advanced template
programming either. But specifically about the ADL problem, I think that bind
is used primarily at a call site to create a predicate. Something that can now
be done with lambda expressions.

That said, I don't like the fact that each and every feature of C++ comes with
a really long list of weird special cases that are impossible to keep in your
head.

------
arocks
I think the article stays away from a criticism of C++ as a language (being
politically correct, perhaps?). Despite knowing most of the answers to the
interview questions in the article, I think I wouldn't call myself an expert
C++ programmer. The spec is extremely large and daunting. C++ is today the
biggest "design by committee" language.

C on the other hand comfortably fits in my head. It might be possible to
declare several complicated declarations (especially with pointers) but the
language is still largely readable. I would argue that many of the extensions
that C++ provides over C feels bolted on (as it was originally) and still not
organically part of the language.

The addition of classes and objects in C++ was seen as the most significant
addition to C. But over time, I have learnt that sophisticated static type
systems like that of ML or Haskell are much more useful and expressive.

At the end of the day we don't need a C on steroids with every feature on the
wishlist and a 2000 page reference manual. We need an easy to use expressive
systems language. I would rather call it "C with some chosen features" rather
than "subset of C++".

~~~
jacquesm
Go appears to be aiming straight for that spot.

~~~
tonyedgecombe
And I hope it makes it. Whenever I write C++ I spend far too much time
thinking about the language and not enough thinking about the problem I'm
trying to solve.

------
shmerl
_> It seems that many of the seasoned developers have forgotten why we stopped
using C++ and moved on to Java, C# and other modern languages._

Did they? Somehow I didn't notice everyone moving to other languages :) C++
has its obvious strengths and is a widely used language. So it doesn't need to
come back - it's already here.

 _> C++ is the wrong direction for the future_

I could accept this argument only if author would focus on fundamental
features that C++ doesn't readily provide - inherent concurrency safety for
example and so on. So languages like Rust can be considered a better direction
for the future which lies in massively multicore architectures. But C#? No,
it's not a direction for the future in comparison to C++.

~~~
rizzom5000
I stopped reading about the time the author implicitly compared C++ to Java
and C#. Sure, these things all share a similar syntax, but one of these things
is not like the others.

~~~
shmerl
Yes, if something can be considered a competing successor of C++ it has to be
from the same compiled family of languages at least.

~~~
rgbrgb
Java was intended as a successor to C++ for the web [1] and I'd say it was
quite successful in that regard.

[1]: <http://www.oracle.com/technetwork/java/intro-141325.html#334>

~~~
shmerl
That's very questionable. "For the Web" argument falls apart if you consider
that Java applets are complete failure. The Web is ruled by JavaScript without
any doubt (and if something, ActionScript/Flash programs on the Web are much
more common than Java ones).

And while as general purpose language Java is used quite a lot, it can't
replace C++ for applications which require best performance. So Java really
fills its own niche, and I wouldn't consider it as a full blown successor of
C++, even if it was intended to be such.

------
Eliezer
Oh _God_ I know the answers to all those interview questions and I remember
_using_ all those features and it seems like an unimaginable Cthulhoid horror
now.

~~~
DanWaterworth
Same here. After I finished reading the article, I felt the need to program
something in Haskell, just to get rid of the smell.

~~~
ihaveajob
It seems like this is the thread where you report 100% success in the
questionnaire, so here I am. Actually, I code in C++, ObjC, JS/HTML5 and
Python almost on a daily basis. I don't think I could have picked up all the
others so quickly if I didn't have a strong C/C++ foundation.

It really helps to know what goes on under the hood. For that, I'd say C++ has
strong didactic value.

~~~
hexagonc
You say, _I don't think I could have picked up all the others so quickly if I
didn't have a strong C/C++ foundation._ , but I ask you this: was it the C or
the C++ foundation that helped you learn the others? I can see how knowing C
could ease the transition to learning JS and ObjC since those both --
superficially at least -- have syntactic similarities to C. But how did
knowing C++ help you with those languages, especially Python and HTML? Was it
mere familiarity with programming in general that helped or was it something
specific to C++?

------
pandaman
The "C++ too complex" story would be very funny if it was not so sad. It
originates from the fake "interview" Bjarne allegedly gave to the "Computer"
magazine, here is an example of it
(<http://harmful.cat-v.org/software/c++/I_did_it_for_you_all> or just google
for "sroustrup x-window interview" there are many similar texts) where Bjarne
allegedly says that the goal of C++ was to be so complex that nobody could
learn it. It was a cute joke but, naturally, people who had problem getting
the joke also had problem learning anything more complex than Java (or Basic,
which was more actual at the time). They honestly believed that they cannot
code not because of their learning disability but the conspiracy to make the
unlearnable language. Over time, the original context has been lost and the
joke became the "common knowledge", everyone knew C++ is just too damn complex
so it's futile even to try to learn, even its creator does not know it etc
etc.

The actual C++, while, indeed more complex than Java, is nowhere close to the
rumored complexity. Say, compared to Common Lisp with 40+ special forms and
things like "loop" and CLOS, it's just too easy (not that I mean CL is
"unlearnable" it's just more complex than C++). Somebody with a STEM degree
could learn C++ better than many self-proclaimed "C++ masters" if just read a
book and then looked over the standard. But very few people do that, the myth
is just too strong.

It's sad because nowadays it gets to the ridiculous point when people will
imagine something about the language rules (something very far from the
reality) and will refuse to write few lines of code to see the stuff just does
not work how they imagined.

The only thing worse than ignorance is false knowledge.

~~~
blue1
there are 25 special operators in common lisp, not 40+.

~~~
pandaman
Sorry, my mistake.

------
rumcajz
The problem with C++ is that you either want to write low-level code, in which
case you ultimately end up using C, or you don't care about low-level stuff,
in which case higher-level languages (python, ruby, java) are much simpler,
make it harder to shoot yourself in the leg etc.

~~~
pubby
Low level is different from high performance. C++ is much higher level than C
yet still retains its performance.

~~~
zanny
It isn't much higher level, it is just more feature rich. You can still, with
minimial tweaking, take any C program and compile it as C++. You just get more
of the kitchen sink with C++, and what the article _doesn't_ mention is how a
subset of that sink makes code simpler, more maintainable, and more logical.

Just by having templates and classes doesn't make it higher level. It just
means it has more feature parity. More higher level is when you can say
"aspect X of the execution environment is _barred_ from the language for the
sake of abstraction, such as Java's garbage collection or Python's list
comprehensions or dynamic types." You _can't_ chose an alternative, so the
level is raised on those issues since the language deals with them for you.

~~~
shawn-butler
I think what you are both trying to say is that C++ was designed to ensure you
"only pay for what you use"? Remarkably successful at that, really.

Kinda falls apart in some cases. For example the standard says with respect to
inline functions that:

An inline function with external linkage shall have the same address in all
translation units.

So I guess for the purpose of not having to worry about comparing the values
of a function pointer to an inline function or worry about assignment
semantics? Actually I have never really understood the point of this part of
the spec.

Anyway, the cost of this is not negligible, since the linker has to maintain
state for those cases where inline replacement is not an option[0]. As a
result, even if you don't use this feature of the language, you pay for it
with increased link time and object file sizes. But this is a pretty arcane
corner case to pick on.

[0]: <http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html>

~~~
zanny
There are dozens of them though, like name mangling bloating code size even if
you forego namespaces. Not saying the compiler doesn't have some inherent
inefficiencies, but it still is operating at the same level as C.

------
halayli
C++ didn't go anywhere to come back. You are probably surrounded by different
people now that don't use C++, and hang out on different sites online.

It feels you are trying to find a language that will fit all problems. What
happened to using the right tool for the job? C++ is one of the best language
choice for a large amount of problems.

------
guilloche
I agree that C++ is complicated, and the future direction is not c++. but
isn't c# supposed to be dead soon? and even MSFT is well prepared to discard
it anytime. C is much simpler than C++. whereever c++ is needed, c is a much
better option.

~~~
damian2000
"The rumors of my death have been greatly exaggerated" - C#, 2012.

------
16s
I think part of the new-found interest in C++ is because of mobile and the
need for performance. Ten years ago, we would write something in Perl, Python
or Ruby and say, "If it runs slow, buy a new computer." Those days are over.
Mobile has re-focused everyone. Code performance matters again and C++ is King
of performance.

~~~
ansgri
Also the increasing popularity of computer vision on those mobile platforms.
You can't realistically do 'serious' CV in anything but C or C++. Maybe in
Python, since it has NumPy and bindings to OpenCV and Leptonica. Though I've
found it difficult to avoid running out of memory.

~~~
seanmcdirmid
C# is ok for CV also, especially if you are just writing some glue code to
interface with the GPU (which is probably C++ like CUDA code).

------
codewright
Eke, not ink.

"Eke out every bit of performance"

~~~
evmar
I also saw that, cringed, and then idly pondered for a bit on whether is more
or less awful than the common "eek out every bit..."

------
hnruss
I feel like every language has a certain domain in which it excels, and every
language has it's detractors.

If there was one language to rule them all, then that's what we'd all be
using.

~~~
tikhonj
> If there was one language to rule them all, then that's what we'd all be
> using.

That's very charitable to programmers. I don't think it's fair to assume that
most--or even many--people choose their language on entirely rational grounds
or the quality of each language.

If you just followed popularity, you'd probably end up using Java, and nobody
wants to go there.

~~~
i386
That's pretty uncharitable to say about Java. If it was a bad language it
wouldn't be so widely adopted. And you can make excellent software with it -
it just depends who's writing the code.

------
malkia
"I used to code in C++ until I took an arrow to the knee"

C + any scripting/dynamic/embedded language is probably a better choice for
future development than C++.

I friend of mine published long time ago in Gamasutra (or was it Gamedev) a
material on.... ahem scripting with C++ - I've talked to him that this is
utter non-sense - scripting is possible in C++, but with thnings like
UnderC++, Ch (only C), Cern's CINT, etc. His material was on implementing a
script-like system using C++ directly.

Then comes boost (he's a big fan of it) - Just a month ago we decided not to
use thrift, but google protobuf simply because it wanted boost. We didn't want
to litter our perforce with tons of files, much bigger increased linking
times, and harder setup. Unfortunately lots of graphics/game /animation
oriented houses/studios use it, so there must be something to it. For me plain
old STL is good, but the best so far has been write C or C++, but do all your
interface in C, only exception being certain hard to make nowadays interfaces
like GUI for example (GTK is example where this is gone wrong too, but with C
- the API is just too big, and lots of macroses).

------
mmphosis
most popular languages through the decades:

    
    
      Python
      Java
      C
      Fortran
    

platform languages:

    
    
      the web browser† = Javascript††
    
      apple = Objective C
    
      microsoft = C#
    
      google = Go
    
      unix = C
    

† the web browser is most importantly platform agnostic

†† Javascript and Java are two different languages. Java is more like C.

Java was once the platform language of now defunct sun.

I consider the language of the linux kernel to be C and i386 assembler. Linux
itself is too much of a bazaar to have a "platform" language.

and a table:

    
    
      lambda calculus | machine memory |
      ----------------+----------------+--------------------
              Haskell | C              | language as given
      ----------------+----------------+--------------------
          Common Lisp | Forth          | language as medium
    

and others:

    
    
      Python vs. Ruby
      Assembler
    
      HTML
      CSS
      SQL
      PHP
    
      Perl
      Prolog
      Basic
      Erlang
    

and yet another...

------
nicholassmith
C++ is great, and it is a huge language to learn, and it does have lots of
pitfalls, and its not easy.

But it'll always be useful in the stack, because like the quote goes its much
harder to shoot yourself in the foot than C is, but with much bigger risks.
It's easy to mitigate those risks and write clean code, but it basically comes
down to only using some subset of the features, C++ sucks the most where it's
in template hell.

It's easy to read all the bad about C++ and avoid it, but its something that's
reasonably easy to pick up and try, and there's a lot of learnable experiences
you can take with you.

------
Itaxpica
A lot of what he says is interesting, but I'm not sure if I agree with what he
says on the educational benefit of C++. That's not to say that learning how to
work at a low level isn't extremely valuable - it is, beyond description - but
I honestly think C++ adds enough abstraction and cruft to actually get in the
way of that goal. In my (totally unqualified) opinion, raw C is a much more
effective way to get a feel for the innards of the machine, without having to
deal with a lot of the overhead that comes from C++.

------
Raz0rblade
Welll it seams this person is right to me, i did some c++ and c# and a dozen
of other languages in the end its more often about development time that make
up development costs.

And if your software is slow, blame it on a slow computer, these days there
are fast computers much more faster then the old days when speed and short
code where seen as an art. The slow computer is a customer cost upgrade, while
taking extra weeks of coding is a softwarehouse cost upgrade.

------
mitchi
I'll keep using my C++ subset, the one that produces great assembly code and
is portable to make the apps/libraries I need. The next big language is
Javascript anyway.

~~~
z3phyr
There's no next big language :]

~~~
DanWaterworth
So true... but there is a next big paradigm; FP FTW! ;)

~~~
ygra
Isn't that what they say for 30 years by now? ;)

------
uonyechi
When you said simpler, I hoped you'd be advocating less abstraction. Anyway,
opinions on C++ largely depend on what kind of software you're developing. If
you're not writing high-performance apps, there are more productive than
languanges than C++. Otherwise, less abstraction is absolutely neccessary
especially for memory management. So C++11 has no choice but to remain as
feature rich as it is. You should have to pick what features to work it.

~~~
eriksank
The problem is that C wipes the floor with C++ in high-performance apps, while
any scripting engine wipes the floor with C++ in terms of abstraction. C++ is
simply losing the war to the combination of C with scripting.

~~~
SomeCallMeTim
C++ is identical in speed to C, if you know what you're doing, even if you're
using "advanced" features. The only thing C exceeds C++ in is simplicity. Yes
you CAN write slow code in C++, but if you need speed, it's there. In the
parts of your code where speed isn't AS important, but you're not ready to
drop to a scripting language, you can manipulate things with higher-level
structures and smart pointers and such.

C++ plus scripting is the best way to go, IMO; you get object-oriented
abstractions, better type safety at compile time, and yet you still get speed.
Destructors alone make it worth using C++ over C, so you can ensure stack
structures clean up on return from a function and can avoid using a "goto
exit" model.

And if you need every last percent of speed, you can write that code in a "C"
subset of C++. C is still completely there under the covers. Except you have
to do more casting.

C is really not much better than a portable assembly language. And I should
know, having written commercial games entirely in assembly language.

------
deltasquared
NaCL on Android, P\Invoke on C#, and JNI on Java exist for a reason.

Sometimes the VM gets in the way, sometimes the library, or bit of hardware
you need to use, only has a C or C++ interface library.

Learning C++ is still important, because, developers who don't understand how
C++ works have little chance of knowing how to find an entry in a COM export
table.

C++ isn't coming back, it never really went away.

------
epistle
I'm new here, though I'm a long-time geezer at /. First post!

My style there was somewhere between civil and uncivil. This never harmed my
karma. I was blunt and/or pointed in my mockery of reasonably smart people
tossing off their pet clichés with their brain on dial-tone. I tried to toe
the line on sharp yet not vindictive. Usually my posts digressed with a
vengeance from an initial sharp retort to something original or constructive.
Writing has always been a thing for me that releases frustration when
technologies are _unnecessarily_ bloody-minded. I wasn't using /. to establish
rapport. But recently the story summaries are achieving new heights of
vagueness. I'm like the old dog who finally caught his tail, and noticed the
smell.

I clearly recall when Paul Graham became a bit of a meme at /. circa 2004. I
still remember the desk I was sitting at when I first read Paul Graham's
comments on LISP. So here we go, wading into the C++ bash-fest for old times'
sake. (Is it permissible to compose in full paragraphs around here? I guess
I'll soon find out. The Y/Z/omega generation's allergy toward paragraphs made
reddit a total non-starter.)

I've definitely let my C++ skills languish for the past few years. It's an
awfully demanding language if it's not your bread and butter.

One way to characterize C++ is that it's an elegance inversion. Most languages
are founded on the assumption that beauty is transitive. If you start with
beauty at the bottom and stay true to your aesthetic all the way up, the
beauty will bloom as a mature rose. The C++ design aesthetic is that the
language designer should not be refactoring his language user's problem domain
in order to shoehorn simplicity (and elegance and glory) into his solution
domain. There were no end of frameworks back in the 1970s and early 1980s that
promised vast productivity increases, and delivered these for the most part,
until the dread day came "oh oh, we have a new requirement and this tool we've
chosen just won't go there, and backing out now is too painful to even
contemplate". (Think Rails, back when every country was laying down a
different rail gauge.)

I find it amusing to read the experience of people deploying MongoDB. The
thing is, regret has a different price than it used to. A few startups report
rapid development on MongoDB for an initial year, then jumping to a different
approach when some of Mongo's design eccentricities became problematic.
Jumping is a lot less hard than it used to be. This might even have been a
good overall development path. Few said that about a major misdirection in the
1980s.

The comment over at the TFA that caused me to sign up and post was a guy
saying that every piece should occupy a limited depth of the abstraction
stack. He took offense that the language should have high level abstractions
and still be able to specify execution details at almost the machine level.

This was actually an almost explicit language design goal. This sentiment is
reminiscent of the old "Worse is Better" debate. (Do I have HTML here? No info
from the UI. Activate telepathy module: throw ("does not compute"). catch
("induction from sparse"): I guess I'll just post the author's name of the
piece I'm referencing: Richard Gabriel.)

C++ doesn't believe that great programs are written on the principle of "no
ugly". Ugly happens. This is a property of reality, is it not? Or am I way too
old for my own good? The premise in C++ is that low level library implementers
have the gory power (pages of closely debated language specification) to
conceal some (or even most) of the ugliness they face. Library implementers
working at the next level up similarly have the gory power to conceal some of
the ugliness they inherit, and also some of the ugliness their own layer
introduces. This continues until the final consumer ends up working at a
fairly high (and reasonably clean) level of abstraction. The ugliness
propagates, but doesn't explode. Incompetence explodes, however, so there is
that.

Of course most casual users of C++ don't appreciate the substrata. They get
buried in the arcane and baroque syntax required to make this magic work.
(C++11 tries to redress this.) This is a whole different tranche of ugliness
that stems from the original decision to keep the C language as a proper
subset (plus a few design missteps along the way that are deeply regretted,
but hard to reverse). Usually on the short list of toxic inheritance from C is
the clever declaration syntax. This didn't generalize to OO without
introducing some ugly ambiguities. Much baroqueness of the language still
stems from this. It's an old language with history, much like Perl. Every new
language arrives with a fresh face. A few get used enough to accumulate
wrinkles. And we've even learned a few things over the years at how to avoid
the worst wrinkles of all. It's nasty, but not ultimately toxic in its own
right.

Not so often admitted by these fresh-faced languages is the relief and freedom
that accrues to not having to profess to solve every possible problem. Why?
Because either C or C++ can be hauled out with a fair certainty that there's
no ugliness so great it can't be captured and expressed well enough.

My own opinion is that C++ has faded into its sunset years by finally buckling
under its own weight. The baroqueness of the syntax is a finite burden, much
like decoding the x86 instruction set as compared to RISC (the amount of
circuitry needed to accomplish fit quite easily into a 386, yet we still
complain about this overwhelming burden 15 die shrinks later). Nevertheless,
it all adds up. I don't think the ROI of learning C++ in a deep way makes
sense for younger developers. It's a complex world. There's too many other
demands for that cognitive space.

That said, I know that if I run into a problem where turning my back on ugly
is not a viable option, C++ is still there for me, with a proven ecology of
ugliness containment. In C++, one can always push ugliness from the problem
domain back into the solution space, at the expense of some source code eye
bleed--supposing your developers are well enough versed to distinguish
incompetent solutions elegantly expressed from competent solutions with an
ugly expression. This is why I described C++ as an elegance inversion.

There are many languages more beautiful where that isn't true. Think of
yourself as a plumber. There's a dirtiness to your world that's simply
inescapable. This doesn't stop plumbers from implementing vacuum reflux hoses
for optimal sewage containment. Then along comes Fritz Haber who declares
sewage obsolete. Be thankful another language built those reflux hoses so your
language doesn't have to.

[Shit, no preview! Edit boxes are pathetic for tweaking paragraph flow. Who
ever looks at their prose any more as others will see it? WTF. Fire and
forget. My first lesson here in the new culture.]

~~~
gregsq
Yeah, thanks for that. I'm a little surprised you haven't had more of a
response to your perspective on all this actually.

There's so many analogies that one could use that I dare not attempt one. Like
if C is like metallurgy, the C++ is like alchemy. I should stop before it
appears foolish.

I've moved from C and C++ in big systems feeding financial instruments at
hundreds of thousands of items a second through rooms full of computers to PHP
and Go and back to C for embedded, where I spend all my time at the moment. So
I fit into one of this articles categories. I had a dirty little problem with
multiple devices sharing a single bus, with all its chip select and clocking
issues, and mutual exclusion with near zero wait states was the problem to be
solved. C++ to the rescue. Not because it couldn't be done in C ( or assembler
for that matter, an even more magic approach ), but because inheriting the bus
made architectural sense.

It isn't hard to read, document or maintain, because the code structure maps
well to the underlying fixed hardware. In this case, the language suits. And
it all has to happen in less than 32K with all the rest of the code.

There's always a lot of discussion about this language versus that. Generally,
I'll use whatever suits, and Javascript and PHP required no learning at all,
and I already knew Java to a degree. They are C'ish enough to pick up without
effort if one already knows C. Objective-C and Go and Java where the shoe
fits, and from what others are saying, Rust is one I need to know.

Independently of Microsofts policy in Windows 8 with IDL and .NET changes, or
tossing the idea around as to whether C or C++ should go in the Objective-C
mix with XCode and Apple, the thing I can use C++ for is making the best
solution possible for fundamental problems with machines, where implementing a
concept over a base or virtual machine facility is efficient. In those cases,
the argument against efficiency fails.

But it's really a specialisation given the volume of solutions that are needed
in the current state of userland software. Horses for courses. There's a lot
more volume now, and managed languages are a better fit in that environment.
This is the house that Jack built. You don't need a hammer and nails. You want
a paint brush.

------
frozenport
"you have to understand exactly what is really going on" WOW, if you said this
at my workplace you would be fired. Good programmers need to know everything
that is going on.

------
philhippus
When you have written something in Java or C# that sells well, I'll rewrite
the same app in C++. My selling point will be a side by side comparison in
performance.

~~~
pkolaczk
A few percent higher performance is not something that will buy you customers.
Especially that after you finish your rewrite, the original will have more
features, better stability (already used and proven in production) and... very
likely better performance. The biggest impact on performance has architecture
an quality of algorithms, not the low-level aspects.

People still like Java Minecraft better than thousands of its C++ clones.

------
therockhead
Binary incompatibility is one of the my biggest issues with C++. Having to
build every library (and its dependencies ) from source is such a pain.

------
jxi
So, the argument is that C++ is too hard to learn for the average programmer,
and that's why it's not "back"?

I don't get it, isn't that win-win is many situations. I'd rather have a solid
developer who can master C++ or at least understand the concepts when
explained to him/her, than someone who can't. Basides dealing with
compiling/linking (but scons greatly simplifies this), I really don't feel
like it limits me much compared to other languages like Python once you know a
bit of STL.

~~~
anuraj
No. There are increasingly lesser avenues where the raw power of C++ will make
a difference. C++ need not be a main stream language when many simpler more
elegant alternatives exist. Use it where it is abosultely necessary - where
active memory management, access to hardware and performance are absolutely
required.

~~~
z3phyr
Is C or haskell an elegant alternative?

~~~
verroq
Writing both performant and readable Haskell is difficult IMHO.

~~~
tikhonj
That's a complicated thing to say. Even unoptimized Haskell tends to be very
good when compared with other high-level languages. (Space leaks are more of
an issue, but they're not _that_ bad and are more than made up for by
Haskell's other relative virtues.)

So for most of your code--the parts that aren't tight and performance critical
--it's good enough as is and you can just stick to writing normal, concise and
(at least in my experience) very readable Haskell.

However, there are always going to be the sections of code that you absolutely
must optimize. And this is certainly not trivial. However, even this isn't too
bad, for two reasons.

The first is that much of the difficultly comes with a lack of familiarity:
you may know how to optimize C++ or C well, but that knowledge is not going to
apply too much. Haskell is very strange, but some people clearly manage to
make it perform well consistently, so it's probably a matter of experience. A
new C++ programmer will find writing heavily optimized C++ code difficult as
well.

The other reason it isn't as bad as it could be is that it's _possible_ at
all. You simply can't write very performant Python, so you essentially _have_
to drop down to C. In Haskell, this is also always an option; however, even
the hard-to-optimize Haskell is still usually friendlier and easier to work
with than C!

In some cases, by using the right libraries and rewrite rules, you can
actually maintain most of Haskell's elegance (like being able to express your
program as composed maps and folds) while still getting good performance.

~~~
fayden
That is actually one of my concerns about Haskell. It's a bit off-topic to
this HN post, but it's relevant to your comment and you seem to have some
experience.

I find Haskell's syntax very elegant and concise, but I am scared about
performances. Often, I read about three or four different ways to do one
thing. If I were to pick Haskell as my go-to language, and let's say I wanted
to build a performant (memory wise and speed wise) program, would I have a
hard time?

Now obviously, for day to day applications, the performance topic is
irrelevant, but how would Haskell compare for the example above instead of,
let's say, Ocaml?

~~~
tikhonj
I think you would have a hard time, but not entirely because of the language's
faults. Rather, the core issue is that most of the things you have to keep in
mind to write fast Haskell (like dealing with laziness) are very different
from what you would have to keep in mind with more common languages that you
are already familiar with.

That said, as I noted, the performance is usually good enough even with
naively written code; you would only have to spend time optimizing a few
select parts of most programs.

Another little problem is that there are not many resources on how to optimize
Haskell code. This is a little annoying if you're learning on your own;
however, I think it's offset by the Haskell community. I've seen some of the
best Haskell programmers give _very_ detailed responses on StackOverflow and
the mailing list, so there is always somebody to help you while you're
learning.

There are also some advantages to OCaml--it's a very fast language itself and
it behaves in a way that's easier to predict especially since you can leverage
more of your existing experience. OCaml is also a very nice languages; while I
prefer Haskell, I would be perfectly happy with OCaml (and, in fact, I've only
used OCaml and not Haskell in production).

I should add a big caveat to this whole post: while I've used both Haskell and
OCaml a fair bit, I've avoided doing anything super performance sensitive. I
usually care more about having correct, readable code quickly than I do about
how fast it runs. So I am definitely no expert on optimizing either Haskell or
OCaml!

~~~
fayden
Thank you for your answer.

------
Roybatty
It seems that the Windows group at Microsoft has a lot of pull , doesn't like
the managed stack, and that's why we're seeing a lot of "native is back" and
C++ article on Microsoft-centered sites.

If that's the case, I wish Microsoft would bite the bullet and come up with a
new native language. Microsoft programmers are for the most part happy C#/.NET
and trying to pull them back to C++ is a losing proposition.

~~~
pjmlp
The funny thing is that there are native code compilers for C#, like bartok in
Singularity and Windows Phone 8 deployment with MDIL.

Languages are not native or managed, implementations are.

The way .NET is currently deployed on Windows and whatever else might be
happening, is a result of internal politcs at Microsoft.

If they wish to do so, they could go fully native with lets say .NET 5.

