Why C++ Is Not "Back"

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 <algorithms>). 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.

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/... (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).

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

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

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.

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.

"Eke out every bit of performance"

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

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

  Python
  Java
  C
  Fortran

  the web browser† = Javascript††

  apple = Objective C

  microsoft = C#

  google = Go

  unix = C

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

  Python vs. Ruby
  Assembler

  HTML
  CSS
  SQL
  PHP

  Perl
  Prolog
  Basic
  Erlang

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.

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.

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.

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

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.

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.