Hacker Poll: Is C++ the Language of the Future? | Hacker News Reader

Hacker Poll: Is C++ the Language of the Future?

readwriteweb.com

44 pointsdlebech66 comments

Have you ever debugged a class that used free instead of delete?

I can't help but think that people that suggest this stuff simply look at lists of features and see "lambda" and think C++ has somehow been modernized. Still fundamentally, it's producing machine code and fundamentally it has a fairly limited runtime and compared to what a LISP coder thinks of when he thinks of closures you might not want to call what C++ has 'closures.' Maybe the fact that the article referenced "lambdas and closures" is what throws me off... that's two features, right? haha The posts that mention C++'s cross platform nature also kind of make me laugh, it's sort of true, it's also remarkably easy to make it not true, just using "int" somewhere will break it some cases and if one of your platforms in Visual C++, then you'll probably have 2 code bases #ifdefed in to one, you can make it work but you have to do some work.

C++ probably won't die, not exactly that languages just die. Microsoft is all in with it, and many other organizations use it. It seems like we are in an era where there is more freedom to match the tool to the job than ever before and I can't imagine starting a medium or large scale project in C++ when Java and .NET are both still very viable. I can't imagine any serious C++ web app development, I can easily see some Ruby, Python or something other calling a chunk of C++ code, but I just can't see it rendering javascript and html in any serious way, it makes very little sense. Now VMs, runtimes, browsers, they'll likely continue to have some C++ in them for some time. It's a fine tool for some jobs. I also find is puzzling, the OpenJDK is GPL, simply Oracle's ownership somehow suggests Java is ending? If that's really what matters, then pretty clearly Go and Objective-C are what the future is, just looking at corporate ownership and momentum.

From a feature matrix? Sure C++ is the next big thing. From reality? I think and hope that it's future use shrinks and becomes more specialized.

I don't think there are many people that have debugged a class that used free instead of delete as there is simply no reason to write the word "free" in a C++ code base.

Even if this somehow happened, allocators include protection at least in debug mode that will let you know when you're doing something obviously wrong.

Writing int won't break your program, I don't see why it would, unless you're making assumptions about range - which you shouldn't. If you need an integer of a certain length there is stdint.h

Even though there is a lot of hate for C++ as a language due to its complexity, it does fit in a niche (cross platform, object oriented native language) that no other language does, although D, Objective-C and Go come close.

I wonder if it'd make sense to develop a Coffee Script style language that compiles a "sane" subset of C++, gets rid of some of the nasty\annoying aspects of C++ (header files), and helps enforce good C++ coding practices (const correctness) but is close to C++.

D feels to me the closest thing to a fixed C++. But without major additional momentum, I don't see how it can ever catch up to C++ in adoption.

D is pretty nice. It has implemented almost everything people suggest when they mention how to fix C++, but it has some major problems as well. It'd have to be supported by a lot of different vendors on different platforms and architectures, and the standard library would has to be straightened out.

What I was proposing is a C++ compiler that could enforce a specific subset of standard C++, along with making things that are generally regarded as best practices default. Because of the complexity of C++ it might have to be a somewhat simplified version of it to work (something like http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...).

in the media arts and "creative coding" world a couple of the frameworks are OpenFrameworks and Cinder, both of which sort of do provide a set of higher level abstractions, but you can always just do the C++ with them as well.

There are few industry standards for C++ that define a more reasonable C++. See JSF C++ Coding standards and MISRA C++. gcc has something like -Werror -Weffc++, which also helps programmers to follow some "best practices".

The key to enforce const correctness is to reverse the default behaviour. Make everything const by default, scrap "const", and introduce "mutable" (or "assignable", or something).

The result hopefully won't feel like a nano-management attempt, while people will think twice before they make anything "mutable".

I think Yes, C++ is the language of the future. It has several strong points, which are still relevant. Namely:

1. cross platform

2. the programmer can choose from several levels of abstractions, as appropriate for a particular project: low-level c-style coding, OOP, templates, meta-programming.

3. even the very high level abstraction usually doesn't induce performance penalty.

4. not using some property of the language doesn't induce performance penalty ("you pay only for what you use" principle).

5. New ISO C++11 standard makes the language even stronger

6. Many design decisions can be expressed by using templates or multiple inheritance, and enforced during compilation.

From internet discussions, I noticed that quite a few people under-appreciate the points 2) and 3), or don't have good understanding about why abstractions are an important part of software design (especially in larger projects).

Also, even in 2011, in a lot of projects the performance achievable only by native code is still very desirable or even required.

I have to challenge some of your points:

2. Just use 2 languages, like C + Lua. or C + anything-higher-level-than-Java. As a "language", such a combination is easily simpler than C++, and the high level part is way cleaner. My point is, don't use one complex tool when 2 simpler one can do.

On a side note, you should think about what OOP, templates, and "meta-programming" are good for. Most of the time, naked lambdas and closures solves OOP's problems in simpler ways. Templates solve parametric polymorphism (or "genericity"), and meta-programming is just a buzzword, as far as C++ is concerned. (When it is not a buzzword, the systems behind are so huge than I wonder if it's worth the effort, see the Boost library.)

3. That one sounds like a lot of work. A high-level and efficient abstraction has to be build from a fairly low level. Efficient memory management for instance, will probably be more complicated than the straightforward (but copy-ridden) RAII scheme.

6. Properly thought out type systems enforce better, and in a simpler way. See Haskell for instance. And even if your high level language is very permissive (Lua, Lisp…), you could still write a custom preprocessor. Not too daunting, as long as the syntax you pre-process isn't C++'s.

What do you mean when you say RAII is copy-ridden?

It's this thing about each object being responsible for the memory allocation of the data it points to:

  // Untested code, I hope I didn't miss anything
  class Foo {
  public:
    Foo(const Bar& b) : b(new Bar(b)) {}
    Foo(const Foo& f) : b(new Bar(*(f.b))) {}
    Foo& operator=(const Foo& f) { b = new Bar(*(f.b));
                                   return *this; }
    ~Foo()throw() { delete b; }
    // other methods
  private:
    Bar* b;
  }

std::auto_ptr<> let you keep your default destructor:

  class Foo {
  public:
    Foo(const Bar& b) : b(new Bar(b)) {}
    Foo(const Foo& f) : b(new Bar(*(f.b))) {}
    Foo& operator=(const Foo& f) { b = new Bar(*(f.b));
                                   return *this; }
    // default destructor
    // other methods
  private:
    std::auto_ptr<Bar> b;
  }

Or you could do away with pointers altogether (not always applicable, and it may fill up your stack too):

  class Foo {
  public:
    Foo(const Bar& b) : b(b) {}
    // default copy constructor, operator=, and destructor
    // other methods
  private:
    Bar b;
  }

So, whenever you need another instance of Foo, it will create another instance of Bar, which may create another instance of Baz… you get the idea. It is quite simple to do, and guarantees the absence of memory leaks, even in the presence of exceptions. But it copies a lot of data. C++ 0x move semantics will make it a little better, but it won't completely eliminate the problem.

Actually, copy is the essence of RAII. Rather than saying "hey, your piece of data is interesting, let me hook it" and later complain when the fish broke your line (dangling pointer), RAII says instead "hey, your piece of data is interesting, let me have a copy" so you are sure to keep your data safe, and the other is sure to be able to safely destroy its own copy at any time.

On a side note, you could avoid copying Bar instances by using Boost's shared pointers or a garbage collector. But it will only be practical if Bar is immutable. I am also told that there are other memory management schemes, which can be very efficient, but tend to be complex and error prone.

The comments on this page are just like C++ itself - all over the place, some of everything. I heard the same comments in the early 90's, when I was doing exclusively C++.

That's why it will still be around 5, 10 and 20 years from now - as long as there's something for everyone to dislike it will also make enough people happy enough to continue using it.

There are two kinds of languages. Those people hate, and those no-one uses.

I have spent around half my career focussing on C++, my current job is half C++ (generally just maintaining old programs, or writing new ones that use old libraries) and half higher level languages (generally preferred over C++).

I think the number of applications where C++ is an appropriate choice for a new project is a lot less now than it was 10 years ago.

Generally a higher level language (Java, C#, Python etc) should be looked at first in most cases, but I am sure C++ will have its niche for a while yet. Like games for example.

Cross platform could indeed be one of those niches, but just being native isn't that big a deal. Python and Java to give a couple of examples are just as compelling options in most cases.

What we need is not a language of the future but a platform.

Look at Java today with it's language ecosystem; scala, clojure, jruby, ...

I'm looking at it right now, and I'm on the verge of projectile vomiting.

The concurrency model will be a key ingredient in "the language of the future" -- right now I would put my money on Google's Go in part because of its concurrency model.

James notes the uncertainty surrounding Java following Oracle's acquisition of Sun, and the uncertainty around .NET as Microsoft seems to be de-prioritizing it in Windows 8.

I can't imagine Java and .NET developers moving to C++ much less enterprises changing course.

Yes the assertion in the linked article that MS is replacing C# with something called "WinC++" is frankly, bizarre, and calls the author's credibility starkly into question.

I find a lot of people complain "C++ is too complicated", but personally i don't think its that hard to get your head around... apart from the cryptic template handling.

Some of my more interesting projects are C++ based so i have a feeling it's going to stick around for quite a while yet.

I think the problem is less that C++ is too complicated, but rather that it is more complicated than it needs to be at almost all tasks where the major pros of C++ don't matter (eg speed) - you're better of using whatever choice of high abstraction language (Python, Ruby, Haskell...) you prefer. And where those pros matter (to stay with the speed example, optimization), you're most likely better of using C or Assembly.

The only real use for C++ I still see is high performance gaming. And I hope that dies out in favor of real games.

C++ is as complicated as you make it. Start with the basics and add on whatever works for you.

I think most people complain that C++ is overly complex because they try to learn it at the same time they try to learn a complex (typically GUI ex. MFC) framework. If you're learning C++ start with backends. Strip it down so that there aren't so many things to learn initially.

The same thing could be said for any language worth a darn. It stands out more for C++ because it's typically only used in heavy lifting situations. It's almost impossible to learn and produce something coherent in this case. Again though that would be true for any language suitable for such situations.

Have you tried to staff a C++ project? If you don't have the ability to easily fire people, it's a horrible pain.

There are tons of people who think they know C++. There are a smaller subset that do.

If you get people who A> Refuse to follow the subset of the language your group is using on the project or B> deeply misunderstand one or two features, you're in total utter hell if you can't fire the person.

Most places don't have an easy enough ability to fire people to do C++ in my opinion, therefore C++ is not suitable for them.

I think that indicates poor interviewing more than anything.

People coding in a different subset of C++ is predictable from an interview? Howso? Not that they know it, but that they prefer it and do it to the contrary of people asking them not to.

Most other languages it doesn't matter anywhere near as much, as idiosyncrasies can be cordoned off well, but with C++, anyone doing anything strange or incompatible anywhere is a problem for most everyone. That same power and control is a curse when people are controlling things two different ways.

In a bigco which takes 6 months to fire someone, this is killer to a project. One guy can destroy a project in that timespan.

C++ has it's place, and that place is "where we can afford pretty high salaries and fire those people who don't work out quickly".

I think that's a bit dramatic. If a coder can't assimilate into your code base and follow the patterns already in use, they would fail regardless of the language.

It's more of a forefront issue with C++. Also, there are tons of ways to write C++, there are very few (relatively speaking) for Java, C, Python, Ruby or Objective-C.

If someone tends to use a different style of dot notation in Obj-C, no biggy, at worse you get a leak or two that an automated tool can find 75% of the time

If someone uses a different type of pointer/reference on a serious chunk of the codebase or a different style of template based inheritance, you're up shit creek really fast.

The language itself has tons of choices all over. The issue is getting everyone on the same page without crushing creative, high spirited people or having to fire otherwise excellent engineers.

I'm not saying the language is useless, I'm saying it is a huge ass staffing pain to get the right mix of engineers who are brilliant and willing to slavishly do what they're told which is hard to find.

The "C++ is only usable in a subset" meme must die.

If you have to keep engineers around who can handle it, it is.

Writing boost heavy code vs STL code vs object oriented code vs prototype based code vs highly functionally styled code vs custom allocated code vs reference passed code vs smart pointer code, interface based code vs heavily multiple inheritance based code vs flat hierarchy mixin template based polymorphism etc.

It gets expensive to keep people who do all of that around with the level of correctness you need to not have weird bugs that take forever to find. It usually means "You have few domain experts" on the team as well (for if the project is say, for financial software, or RF controllers, or modems, etc).

You mostly need engineers who think converting between 15 different types of strings is a useful use of developer time.

So your argument essentially boils down to "there should be some coding style in a project", which is true for all languages, not just C++.

>which is true for all languages, not just C++

No it's not. Lots of languages have broad based understanding of good and bad based on some body, consensus, etc, that does not have mutually incompatible schools of thought that combust wildly when stuck in the same project.

I've never seen a ruby project with a code style guide.

While I've seen python ones (the language closest to C++ in getting randomly hairy different types), the mixups tend to be relatively benign comparatively speaking. Most python projects go with "Look PEP8ish/pythonic".

Objective-C is heavily driven by WWDC presentations and strong recommendations by Apple, so people tend to move to that.

C is all over the map as well, but again, individual complexity of each decision is much lower. You'll have a style guide at a C dev company. "Use lint with these flags and indent with this specifications" is what the best ones have for a majority of their work.

Perl tends to not care, same for php, whereas I think they really should care more.

C#? I've seen style guides, but they're only on about 10-30% projects.

Java: they're usually there.

>"there should be some coding style in a project",

This all comes out to: making all these decisions in a consistant style is MANDATORY for a C++ project. For most others, there are conventions which don't blow things up that make people work generally to a similar enough style. While there may be some codified choices, with C++ in particular, you have TONS of choices, choices that your staff will not all have the same opinions on, choices you'll have to get them onboard with using, onboard with understanding, and thinking in terms of those mechanisms.

That's relatively hard to do. There's so much ramming shit down people's throats in C++ projects that I think it's only worth it in a small small number of cases.

That's not a meme, that's life.

Well, that's true of many languages, Perl for example has gotten a bad rep because everyone on the project asserts their right to "there's more than one way to do it". S'what code reviews are for.

I don't think C++ is the language of the future.

I do think we'll see languages that espouse some of the same guiding principles of C++, namely: multiple paradigms, only paying for what you use, native compilation options, and compile-time metaprogramming.

As it stands now, it has a huge marketing problem that's been perpetuated by a meme of "omg complexity!!!!!111," (aside: it's goofy how fashion-oriented developers are) so C++ in its current form could never rise up.

Big C++ fan here. I came to C++ after learning Python. I simply love it and the Boost libraries only make it better.

If I could only have one programming language, it would definitely be C++. I can do anything with it on any operating system. No vendor or IDE or build environment lock in. It's a solid ISO standard with multiple compiler support.

I still use bash, Python and Ruby for quick test scripts and prototyping and I like them as well.

It's not a solid ISO standard. One of my coworkers recently gave me a c++ library to use. I linked to it and started making calls and found out that the STL from his compiler ( VS 2003) was incompatible with the STL from my compiler (VS 2010). They were simple things, like function calls that had their types changed, but nonetheless it rendered his library useless to me.

Compare to C, where everything is heavily standardized and you can use libraries from different compilers without much difficulty.

I don't like C++ as a language AT ALL, but the fact is, for cross-platform native app development, it's the only game in town unless you want to write C. Do you want your app (or some part of your app) to run on Windows/OSX/iOS/Android/Linux? Then you're writing it in C++.

It sucks, in many ways, but it's what we have.

Actually there is no reason not to use Objective C, since gcc can compile that too.

Because there is no class library that is multi-platform and integrates somewhat nicely into the platform. Yes, I know GNUStep, but it doesn't come close to e.g. Qt in terms of integration.

Sure there is. Primarily the requirement to have a runtime installed followed secondarily by the fact that many of the useful features are encapsulated in Apple specific libraries (or NeXT Step, although GNUStep takes care of that on many platforms).

Every other complaint I have against the language just stems from my familiarity with C++ and love of static typing (or compiler hints and syntactic niceties useful for writing high performance code - namely games).

Or C#, which runs on all of the platforms you named and a few others as well.

Actually, using Python or similar is pretty attractive option for Gui development. I know it isn't hip to use WxWindows or Qt4, but if you want a gui that works on all three major platforms Python + Qt4/Wx is a pretty good way to go. Salt this opinion with all the usual trade offs of using Python and the trade offs of not using a "native" toolkit.

As the closest relative to C, and the cross-platform language, tech world can't really live without it. But you can, of course... is it the programming language of the future? I think the programming language of the future hasn't been created yet.

I am limiting this prediction to mass-consumed applications of technology.

If we extrapolate (obligatory: http://xkcd.com/605/) present trends it seems that the platform of the future will be the web.

This will require fast internet connections on computing devices (whatever those will look like in 10 years) as pervasive as water and electricity in the rich world. And we are getting there.

So the language of the future will be based on this platform. The obvious choice then would be javascript. But javascript has a lot of problems so most likely someone will invent a language of the form javascript++ within a few years.

How about we just end this speculation over what is the next big language, and just check back in 5 or 10 years and see what is actually popular and useful.

There's so much that can change in one year let alone five or ten, therefore it isn't easy to make predictions that far out.

For the record I use C++ in a day job, and there's an awful lot of code written in it, so it will exist in some form or other for a very long time to come. Need I mention COBOL? There's also enough stuff written in Java, C#, Visual Basic, JavaScript, Ruby, and Python for them to easily last into the next decade.

As macavity23 said (http://news.ycombinator.com/item?id=2766974), C++ has certain strengths, and because of that, I think it will be around for a long, long time.

But at the same time, developers will prefer working in higher-level (more productive) languages whenever possible.

So, IMHO, C++ is a language of the future, not the language of the future.

I think C++ is possibly the worst language still mainstream. It's just horrible, in so many ways.

I really hope people will stop doing such silly things, but realistically, it's unlikely to change too soon.

I think c++ is great to learn on, but I hate working with it day in and day out. It's also close enough to objective-C and also to C# that it's going to remain valuable to learn.

I hope some kind of Open VM comes in future so that languages can evolve independent of libraries. It will be awesome to run C# and Java on the same VM.

Why on earth would anyone want to use Java the language on anything else than JVM and get rid of the one and only alleged advantage that Java has?

Take a look at Parrot

http://www.parrot.org/

My bet is on Go. Once the gates are open, the flood will bring em to the top. Go on the browser, server, mobile, desktop, os, everywhere. By Google.

It is a language that will be used well into the future. There will be no 'the' language. These things are silly.

I've been using C++ almost exclusively for over a decade. C++ is wonderful, powerful, ugly, and dangerous. It's entirely dependent upon the developer, and it varies with popular trends. Just when you master something like Boost, you move to a new company where you aren't allowed to use it. Everyone preaches his own religion of whitespace, best practices, and patterns.

Lately, I've found the ugliness inescapable and deeply irritating:

    for (std::vector<mytype>::const_iterator i = myinst.begin() ...

The repurposing of the 'auto' keyword in C++0x can greatly reduce this ugliness:

    for (auto i = myinst.begin() ...

But, of course, people will abuse auto and have "auto n = 5;" (a 'foreach' makes this even cleaner, but the above syntax exemplifies other situations as well)

I've recently been doing a bit of C# coding again. I'm stunned at how quickly I get get stuff working, mostly because .Net contains all the boilerplate I would either write myself, or have to track down in 3rd party libraries. I wrote a page scraping tool the other day in C#, on my Mac, in vim, with the Mono C# compiler. I had it done in under an hour, and it runs on both platforms I use. My productivity increased by about 8x (clearly not universally applicable), and my enjoyment increased even more.

So, no, C++ probably isn't the future. The future probably looks like Python and Javascript on the web, C# in business applications, and plain C at the bottom.

I don't use C/C++ for the same reason I don't use assembly. There are superior languages out there that do a better job with everything important for building complicated software that is robust, easy to use, easy to maintain, fast and scalable. C++ is on its way out, it is still relevant and will be relevant for decades though. As is Cobol.

There are superior languages out there that do a better job

Your statement is false, because the choice of language depends on the job. For example, when I need to make something simple quickly I will do it in C#. However when I need to write an add-on to an existing application that doesn't have an official plugin system, then C++ and Assembly are really awesome.

It seems you missed his qualifier: "for building complicated software that is robust, easy to use, easy to maintain, fast and scalable"

Complicated + robust + easy to maintain is plain impossible in C++. Also, add-ons fit "enhance software" better than "building software".

Complicated + robust + easy to maintain is plain impossible in C++. I don't think so.

Also, add-ons fit "enhance software" better than "building software". Your "building software" could also be labeled as enhancing the operating system.

There are times when it is appropriate to select C/C++ for the job, that is when enhancing a project written in C++.

(1) Okay, let's speculate about the actual requirements for robust, easy to maintain software. Robust means it won't fail easily. A robust program handles edge cases correctly, and have few errors. An easy to maintain program is one that is easy to correct or modify. To achieve this, you must make it so that most modifications require the inspection of relatively few code. It means the code base must be either small or very well de-coupled.

Now let's add "complicated". To me, it means the problem cannot be solved by a small program. Therefore, the program will be rather big. To achieve robustness and ease of maintenance, you have to make it locally readable and modular.

Now, add "in C++". C++ is extremely permissive. You can tweak almost anything. It can be awesome, but there is a flip side: memory must be handled manually (more code), and you can make fewer assumptions about your program (less modular code). For an originally complicated problem, this is a significant burden.

Now, a very disciplined team could overcome this burden. Just mind a few things: Const correctness everywhere, and avoid side effects where you can (this is both extremely important[1] and not easy in C++[2]). Ban or restrict the use of the more problematic features (I would mostly scrap inheritance, except when emulating Java interfaces). Use the remaining features in a standardized manner (make sure copy constructors and destructors are correct, use initialization lists systematically or not at all, make everything exception-safe or ban exceptions, use std::auto_ptr<> as much as possible, and probably a gazillion other crucial things I forgot).

Some individuals are indeed that disciplined. But an entire team? Good luck finding it.

(2) The API of most operating systems are sufficiently language independent to allow several languages. Most languages are sufficiently OS independent to allow the port of programs in several operating systems. This is basically because an OS API and standard libraries are effectively the two halves of a plug-in system.

So, the constraints are very unlike those you find when adding functionality to a program which doesn't have any plug-in system. I concede that C and C++, as the default API for current operating systems, are favoured. But the burden on other languages is barely noticeable (except maybe for the language implementer).

[1]: http://www.loup-vaillant.fr/articles/assignment

[2]: http://www.loup-vaillant.fr/tutorials/avoid-assignment

And yet fascinatingly enough, people still write Assembler code. (Especially with the popularity of JITs these days, a decent number of programmers know Assembler). And if perhaps you do not solve problems that C++ is designed to solve. That's find. Don't say that C++ is useless for that reason.

What do you consider those languages to be?

My personal guess would be "anything higher-level than Java, plus C". From there, fights over Haskell vs Lisp vs Python vs Lua probably hit a point of diminishing returns (but it's still worth it to talk about it).

Oh Jesus. I did my 2 years of C++ development over 10 years ago, but I don't even mention it in my CV, because I am not going to use the mess that is C++ ever again. If I need something low-level, I will use Objective-C.

Reply on news.ycombinator.com