

Hacker Poll: Is C++ the Language of the Future? - dlebech
http://www.readwriteweb.com/hack/2011/07/hacker-poll-cpp.php

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

~~~
blub
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

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

~~~
loup-vaillant
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.

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

~~~
loup-vaillant
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.

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

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

~~~
Impossible
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...](http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
turbojerry
Take a look at Parrot

<http://www.parrot.org/>

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

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

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

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

~~~
Strom
_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.

~~~
loup-vaillant
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".

~~~
Strom
_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.

~~~
loup-vaillant
(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>

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

