13 ms·

Why C++ Is Not "Back"

130 points by jsonmez 14y ago

shmerl 14y ago
> 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 14y ago
  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 14y ago
    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 14y ago
      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 http://www.oracle.com/technetwork/java/intro-141325.html#334
      - shmerl 14y ago
        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.
  - seanmcdirmid 14y ago
    There was a time when C++ was it, it was the present and the future. Then Java came out and C++ was increasingly relegated to niche use cases (device drivers, games, HPC). No one would ever dream today of writing a web service in C++, but back in 1995, that definitely wasn't the case. As a related aside, Microsoft recently enabled us to use C++ for WinRT UI apps; keep in mind that WPF (WinRT's predecessor) only supported C# and VB (well, their was the CLR version of C++, but who used that?). So now you can write your Win8 metro app in C++ if you want, but why go through the pain and misery of doing that? Why choose C++ if C# is good enough for what you are doing?
- beatgammit 14y ago
  I completely agree. I wish the author had mentioned one of the other replacements for C++, like D, Go or, as you mentioned, Rust. C++ can't be fixed by adding to it. That's how it got so unmanageable in the first place. Personally, I just write in C when I need performance, but then again, I don't work on large projects that need raw speed. For me, D and Go are good enough. They beat the pants of any interpreted language, and they offer compelling features not found in C++ (like simplicity, have you seen D's templates? Work of art...).
  - tikhonj 14y ago
    I don't think Go is any more appropriate as a comparison to C++ than Java or C# are. After all, Go essentially competes in the same space as Java and C#--it's a managed imperative language designed for use on a server. Now, D and Rust are another story. After doing a bit of reading, I'm actually very excited about Rust. For me, Go is essentially completely useless: it fills the same niche as Java, C# or--far more importantly--Haskell or OCaml. If I need code that's relatively fast but don't want to sacrifice memory safety or the convenience of a high-level language, I can do much better than Go. On the other hand, if I want really low-level access to the system, for whatever reason, I don't have many good choices. I could do C, but that's rather unsafe and unpleasant; I could do C++, but it's a gigantic, overly complex language and also rather unsafe and unpleasant and I could do D. (I've actually heard good things about D but have never tried it.) Rust gives me the perfect alternative--a simpler, higher-level language that's more pleasant to use but still lets me operate at a relatively low level. So next time I need to do something like that (which, honestly, probably won't be soon), I'm almost definitely going to use Rust, even if it's in active development and changing all the time. EDIT: In re-reading this comment, I have realized that "high-level" and "low-level" really aren't great terms (at least the way I'm using them). Particularly, they're not mutually exclusive: a language can both support a high level of abstraction and provide low-level systems access where needed. Of course, I can't think of any language that actually does this, but Rust seems very promising.
    - acqq 14y ago
      If you're doing anything serious, you need something that is going to compile even when compiler changes from version to version, unless you plan to write only a few lines, when it doesn't matter which language is used anyway. That's why I don't understand your argument for Rust. I'd vote for D.
- alephnil 14y ago
  > Did they? Somehow I didn't notice everyone moving to other languages Neither did the FORTRAN and COBOL programmers back in the days. The reason is that there were plenty to do (and still is) for those already involved. That is also the case to a less degree with C++. It is just that most of the growth has been elsewhere. You won't find much web programming in C++, which is the area where the largest growth has been. There sure is some, I even have encountered web application in FORTRAN, but most web applications are written in PHP, Java, Ruby, Python and others, not C++.
  - shmerl 14y ago
    Comparison is not valid, since I'm considering many new projects. For example parallel computing (massive data processing) is mostly done in C++. Intensive 3D games are written in C++ as well. Just about anything that needs critical performance is written in C++. So we aren't talking just about legacy code, we are talking about new development.
    - alephnil 14y ago
      > Comparison is not valid, since I'm considering many new projects. If C++ had never been considered for new projects, it would have been in sharp decline, which it is not. What I said was that most of the growth has been elsewhere, like in web where there is hardly any C++, and mobile apps, where there is relatively little C++ (some on iOS, but Objective C dominates there). My main point was that as long as the whole industry is in growth, you may not notice that the world has moved on, at least not if you measure the health of X by the "still new projects in X".
codewright 14y ago
Eke, not ink. "Eke out every bit of performance"
- evmar 14y ago
  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..."
guilloche 14y ago
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 14y ago
  "The rumors of my death have been greatly exaggerated" - C#, 2012.
- pjmlp 14y ago
  C yuck! Nowadays I won't change the power and extra safety given to me by C++ with C, unless requested by customers, which no one was made since 2001 in my case.
jxi 14y ago
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 14y ago
  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 14y ago
    Is C or haskell an elegant alternative?
    - verroq 14y ago
      Writing both performant and readable Haskell is difficult IMHO.
      - z3phyr 14y ago
        Difficult does not mean not elegant. For example, I find ruby more elegant and pragmatic than python though ruby is relatively difficult. Now the real part : Is haskell difficult or is it strange?
      - tikhonj 14y ago
        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.
general_failure 14y ago
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/bind/bind.hpp 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).
- z3phyr 14y ago
  What are your views on Haskell? Very difficult to master - that's why bad?
- mitchi 14y ago
  I agree with everything you've said. C++ with templates is absolutely terrifying to read sometimes. Not to mention these error messages and the bloat, the bloat.
  - zvrba 14y ago
    ... and the compile-times :S
- Negitivefrags 14y ago
  Linking boost bind is unfair. I find it ironic that you dislike C++11 but the example you link to is only bloated due to the lack of the very same features that C++11 adds (in this case variadic templates would make that file 10 times smaller). And it only really exists in the first place to paper over the lack of lambda functions, which C++11 also added. Modern C++11 code is much easier to read and understand. The majority of added features are all about promoting that very ideal.
mitchi 14y ago
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 14y ago
  There's no next big language :]
  - DanWaterworth 14y ago
    So true... but there is a next big paradigm; FP FTW! ;)
    - ygra 14y ago
      Isn't that what they say for 30 years by now? ;)
- deleted 14y ago
  [deleted]
rumcajz 14y ago
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 14y ago
  Low level is different from high performance. C++ is much higher level than C yet still retains its performance.
  - zanny 14y ago
    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 14y ago
      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 http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html
Eliezer 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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++?
      - oelewapperke 14y ago
        I would argue that C++ is a language that effectively encompasses all other (imperative) languages. Where other languages have a few options, C++ has all of them. If you know C++ you know everything a cpu is capable of. In practice all ther other languages JS/ObjC/Java/... essentially take C++ and take out parts of the language. This makes it very easy and very fast to get a good understanding of any (imperative) language for a C++ engineer.
hnruss 14y ago
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 14y ago
  > 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 14y ago
    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.
halayli 14y ago
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.
SomeCallMeTim 14y ago
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 <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.
- deleted 14y ago
  [deleted]
- seanmcdirmid 14y ago
  > 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.
arocks 14y ago
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 14y ago
  Go appears to be aiming straight for that spot.
  - tonyedgecombe 14y ago
    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.
- jjtheblunt 14y ago
  "the biggest "design by committee" language" : facts? Bigger than Common Lisp?
  - seabee 14y ago
    How long is the spec for CL? It surely is a tenth of the C++ spec.
malkia 14y ago
"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).
uonyechi 14y ago
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 14y ago
  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 14y ago
    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.
Itaxpica 14y ago
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++.
therockhead 14y ago
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.
pandaman 14y ago
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 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 14y ago
  there are 25 special operators in common lisp, not 40+.
  - pandaman 14y ago
    Sorry, my mistake.
frozenport 14y ago
"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.
deltasquared 14y ago
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.
philhippus 14y ago
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.
- eriksank 14y ago
  The C++ implementation will still lose from an implementation that did the low-level mechanisms -- aka the 1% inner loops -- in C and the remainder with a scripting engine. C++ will not be faster but it will surely be more complicated to deal with. Java and C# are not really the alternatives. It is C + scripting that is.
- pkolaczk 14y ago
  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.
Raz0rblade 14y ago
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.
16s 14y ago
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 14y ago
  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 14y ago
    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).
mmphosis 14y ago
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 14y ago
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.
epistle 14y ago
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.]
Roybatty 14y ago
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 14y ago
  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.
- damian2000 14y ago
  I get the feeling that they are no so much pulling C++ back as rather more prominently showing us where it has always been. There has always an underlying C/C++ based Win32 and kernel library for example, but the .NET BCL hid much of that. Now in Win8, C++ is a first class citizen for designing Windows UIs again, along with C#.

130 points by jsonmez 14y ago

> 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 14y ago
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 14y ago
  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 14y ago
    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 http://www.oracle.com/technetwork/java/intro-141325.html#334
    - shmerl 14y ago
      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.
- seanmcdirmid 14y ago
  There was a time when C++ was it, it was the present and the future. Then Java came out and C++ was increasingly relegated to niche use cases (device drivers, games, HPC). No one would ever dream today of writing a web service in C++, but back in 1995, that definitely wasn't the case. As a related aside, Microsoft recently enabled us to use C++ for WinRT UI apps; keep in mind that WPF (WinRT's predecessor) only supported C# and VB (well, their was the CLR version of C++, but who used that?). So now you can write your Win8 metro app in C++ if you want, but why go through the pain and misery of doing that? Why choose C++ if C# is good enough for what you are doing?
beatgammit 14y ago
I completely agree. I wish the author had mentioned one of the other replacements for C++, like D, Go or, as you mentioned, Rust. C++ can't be fixed by adding to it. That's how it got so unmanageable in the first place. Personally, I just write in C when I need performance, but then again, I don't work on large projects that need raw speed. For me, D and Go are good enough. They beat the pants of any interpreted language, and they offer compelling features not found in C++ (like simplicity, have you seen D's templates? Work of art...).
- tikhonj 14y ago
  I don't think Go is any more appropriate as a comparison to C++ than Java or C# are. After all, Go essentially competes in the same space as Java and C#--it's a managed imperative language designed for use on a server. Now, D and Rust are another story. After doing a bit of reading, I'm actually very excited about Rust. For me, Go is essentially completely useless: it fills the same niche as Java, C# or--far more importantly--Haskell or OCaml. If I need code that's relatively fast but don't want to sacrifice memory safety or the convenience of a high-level language, I can do much better than Go. On the other hand, if I want really low-level access to the system, for whatever reason, I don't have many good choices. I could do C, but that's rather unsafe and unpleasant; I could do C++, but it's a gigantic, overly complex language and also rather unsafe and unpleasant and I could do D. (I've actually heard good things about D but have never tried it.) Rust gives me the perfect alternative--a simpler, higher-level language that's more pleasant to use but still lets me operate at a relatively low level. So next time I need to do something like that (which, honestly, probably won't be soon), I'm almost definitely going to use Rust, even if it's in active development and changing all the time. EDIT: In re-reading this comment, I have realized that "high-level" and "low-level" really aren't great terms (at least the way I'm using them). Particularly, they're not mutually exclusive: a language can both support a high level of abstraction and provide low-level systems access where needed. Of course, I can't think of any language that actually does this, but Rust seems very promising.
  - acqq 14y ago
    If you're doing anything serious, you need something that is going to compile even when compiler changes from version to version, unless you plan to write only a few lines, when it doesn't matter which language is used anyway. That's why I don't understand your argument for Rust. I'd vote for D.
alephnil 14y ago
> Did they? Somehow I didn't notice everyone moving to other languages Neither did the FORTRAN and COBOL programmers back in the days. The reason is that there were plenty to do (and still is) for those already involved. That is also the case to a less degree with C++. It is just that most of the growth has been elsewhere. You won't find much web programming in C++, which is the area where the largest growth has been. There sure is some, I even have encountered web application in FORTRAN, but most web applications are written in PHP, Java, Ruby, Python and others, not C++.
- shmerl 14y ago
  Comparison is not valid, since I'm considering many new projects. For example parallel computing (massive data processing) is mostly done in C++. Intensive 3D games are written in C++ as well. Just about anything that needs critical performance is written in C++. So we aren't talking just about legacy code, we are talking about new development.
  - alephnil 14y ago
    > Comparison is not valid, since I'm considering many new projects. If C++ had never been considered for new projects, it would have been in sharp decline, which it is not. What I said was that most of the growth has been elsewhere, like in web where there is hardly any C++, and mobile apps, where there is relatively little C++ (some on iOS, but Objective C dominates there). My main point was that as long as the whole industry is in growth, you may not notice that the world has moved on, at least not if you measure the health of X by the "still new projects in X".

codewright 14y ago

Eke, not ink. "Eke out every bit of performance"

evmar 14y ago
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..."

guilloche 14y ago

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 14y ago
"The rumors of my death have been greatly exaggerated" - C#, 2012.
pjmlp 14y ago
C yuck! Nowadays I won't change the power and extra safety given to me by C++ with C, unless requested by customers, which no one was made since 2001 in my case.

jxi 14y ago

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 14y ago
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 14y ago
  Is C or haskell an elegant alternative?
  - verroq 14y ago
    Writing both performant and readable Haskell is difficult IMHO.
    - z3phyr 14y ago
      Difficult does not mean not elegant. For example, I find ruby more elegant and pragmatic than python though ruby is relatively difficult. Now the real part : Is haskell difficult or is it strange?
    - tikhonj 14y ago
      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.

general_failure 14y ago

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/bind/bind.hpp 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).

z3phyr 14y ago
What are your views on Haskell? Very difficult to master - that's why bad?
mitchi 14y ago
I agree with everything you've said. C++ with templates is absolutely terrifying to read sometimes. Not to mention these error messages and the bloat, the bloat.
- zvrba 14y ago
  ... and the compile-times :S
Negitivefrags 14y ago
Linking boost bind is unfair. I find it ironic that you dislike C++11 but the example you link to is only bloated due to the lack of the very same features that C++11 adds (in this case variadic templates would make that file 10 times smaller). And it only really exists in the first place to paper over the lack of lambda functions, which C++11 also added. Modern C++11 code is much easier to read and understand. The majority of added features are all about promoting that very ideal.

mitchi 14y ago

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 14y ago
There's no next big language :]
- DanWaterworth 14y ago
  So true... but there is a next big paradigm; FP FTW! ;)
  - ygra 14y ago
    Isn't that what they say for 30 years by now? ;)
deleted 14y ago
[deleted]

rumcajz 14y ago

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 14y ago
Low level is different from high performance. C++ is much higher level than C yet still retains its performance.
- zanny 14y ago
  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 14y ago
    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 http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html

Eliezer 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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++?
    - oelewapperke 14y ago
      I would argue that C++ is a language that effectively encompasses all other (imperative) languages. Where other languages have a few options, C++ has all of them. If you know C++ you know everything a cpu is capable of. In practice all ther other languages JS/ObjC/Java/... essentially take C++ and take out parts of the language. This makes it very easy and very fast to get a good understanding of any (imperative) language for a C++ engineer.

hnruss 14y ago

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 14y ago
> 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 14y ago
  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.

halayli 14y ago

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.

SomeCallMeTim 14y ago

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

deleted 14y ago
[deleted]
seanmcdirmid 14y ago
> 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.

arocks 14y ago

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 14y ago
Go appears to be aiming straight for that spot.
- tonyedgecombe 14y ago
  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.
jjtheblunt 14y ago
"the biggest "design by committee" language" : facts? Bigger than Common Lisp?
- seabee 14y ago
  How long is the spec for CL? It surely is a tenth of the C++ spec.

malkia 14y ago

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

uonyechi 14y ago

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 14y ago
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 14y ago
  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.

Itaxpica 14y ago

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

therockhead 14y ago

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.

pandaman 14y ago

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 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 14y ago
there are 25 special operators in common lisp, not 40+.
- pandaman 14y ago
  Sorry, my mistake.

frozenport 14y ago

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

deltasquared 14y ago

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.

philhippus 14y ago

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.

eriksank 14y ago
The C++ implementation will still lose from an implementation that did the low-level mechanisms -- aka the 1% inner loops -- in C and the remainder with a scripting engine. C++ will not be faster but it will surely be more complicated to deal with. Java and C# are not really the alternatives. It is C + scripting that is.
pkolaczk 14y ago
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.

Raz0rblade 14y ago

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.

16s 14y ago

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 14y ago
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 14y ago
  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).

mmphosis 14y ago

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 14y ago

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.

epistle 14y ago

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

Roybatty 14y ago

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 14y ago
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.
damian2000 14y ago
I get the feeling that they are no so much pulling C++ back as rather more prominently showing us where it has always been. There has always an underlying C/C++ based Win32 and kernel library for example, but the .NET BCL hid much of that. Now in Win8, C++ is a first class citizen for designing Windows UIs again, along with C#.