Anyone else feel like C++ is getting too complicated?

[Zachary Turner]

I know I'm going to get flamed here, but I really feel like C++ is
just getting way too complicated to be as practical as I feel it
should (and could) be. Before you start, I've been doing C++
professionally for probably 12 years, it's easily my strongest
language, and I consider myself a "C++ programmer", not a programmer
of some other language. I'm pretty comfortable with probably 90% of
what's in C++98, and have played around quite a bit (and actually
rather enjoy) things such as template metaprogramming and other more
advanced applications of C++.

But looking at what's coming in C++0x, I'm starting to feel like it's
just going too far. It actually started with Boost. I mean I greatly
value the genericity and flexibility of the utilities that boost
provides, but honestly, every time I need a new class that Boost
provides, it takes me an hour just to figure out what the heck the
documentation is talking about. Even for things which SHOULD be
simple. The other day I needed a pool, I figured "hey I bet boost has
a pool". Sure enough it did, and after an hour I realized it was a
waste of time and I could have written the class I needed in about 5
minutes, so I did. As another example, look at the date time library
in boost. It's insane and it takes forever even to figure out how to
use it in the most basic ways. MPI is even more ridiculous, if you
can even come close to understanding how MPI and Lambda work, you
deserve a PhD in something, for real.

I'm getting off a little off topic talking about boost, but the
principle is carrying over into C++0x, albeit with basic syntax
issues. There are a few saving graces to C++0x, most notably I think
the type inference features being introduced are long overdue and
frankly pretty amazing. But rvalue references? I've tried explaining
these to FIVE different C++ programmers, and nobody has any idea what
I'm talking about. It's like I'm trying to teach them Haskell or
Hungarian, or something. But it sure doesn't sound to them like I'm
talking about C++. Concepts are almost as bad. I mean the intention
is in the right place, but that was the case with templates as well,
and I've actually quit TWO jobs over the fact that I had inherited
someone else's template code, and it was fundamentally ruined because
the person didn't understand how to correctly design large-scale
template libraries. In one case, after I quit I was told by a former
colleague that the company wrote into their coding standard that
templates were strictly forbidden from all future use, with the
exception that standard library templates could be used. Just that no
future template classes could be created.

My heart is and always has been with C++, but honestly if these trends
continue I might find myself honing my expertise in other languages in
the (near) future. C++ is still an amazing language if you're on a
team full of other people who have written a standards conformant C++
compiler, but in the real world where most of your colleagues are
average (by definition of the word average), it's becoming more
painful than it is enjoyable.

Agree? Disagree? Flame?

 

[Alf P. Steinbach]

* Zachary Turner:

I know I'm going to get flamed here, but I really feel like C++ is
just getting way too complicated to be as practical as I feel it
should (and could) be. Before you start, I've been doing C++
professionally for probably 12 years, it's easily my strongest
language, and I consider myself a "C++ programmer", not a programmer
of some other language. I'm pretty comfortable with probably 90% of
what's in C++98, and have played around quite a bit (and actually
rather enjoy) things such as template metaprogramming and other more
advanced applications of C++.

But looking at what's coming in C++0x, I'm starting to feel like it's
just going too far. It actually started with Boost. I mean I greatly
value the genericity and flexibility of the utilities that boost
provides, but honestly, every time I need a new class that Boost
provides, it takes me an hour just to figure out what the heck the
documentation is talking about. Even for things which SHOULD be
simple. The other day I needed a pool, I figured "hey I bet boost has
a pool". Sure enough it did, and after an hour I realized it was a
waste of time and I could have written the class I needed in about 5
minutes, so I did. As another example, look at the date time library
in boost. It's insane and it takes forever even to figure out how to
use it in the most basic ways. MPI is even more ridiculous, if you
can even come close to understanding how MPI and Lambda work, you
deserve a PhD in something, for real.

I'm getting off a little off topic talking about boost, but the
principle is carrying over into C++0x, albeit with basic syntax
issues. There are a few saving graces to C++0x, most notably I think
the type inference features being introduced are long overdue and
frankly pretty amazing. But rvalue references? I've tried explaining
these to FIVE different C++ programmers, and nobody has any idea what
I'm talking about. It's like I'm trying to teach them Haskell or
Hungarian, or something. But it sure doesn't sound to them like I'm
talking about C++. Concepts are almost as bad. I mean the intention
is in the right place, but that was the case with templates as well,
and I've actually quit TWO jobs over the fact that I had inherited
someone else's template code, and it was fundamentally ruined because
the person didn't understand how to correctly design large-scale
template libraries. In one case, after I quit I was told by a former
colleague that the company wrote into their coding standard that
templates were strictly forbidden from all future use, with the
exception that standard library templates could be used. Just that no
future template classes could be created.

My heart is and always has been with C++, but honestly if these trends
continue I might find myself honing my expertise in other languages in
the (near) future. C++ is still an amazing language if you're on a
team full of other people who have written a standards conformant C++
compiler, but in the real world where most of your colleagues are
average (by definition of the word average), it's becoming more
painful than it is enjoyable.

Agree? Disagree? Flame?

At meeting of Oslo C++ User Group I asked how many knew of MPL. 1 out of approx
12 did. I think, in fact pretty sure, that those 12 were among the most
enthusiastic C++ programmers in Norway.

So I think you're right that there's a gap between the direction the language &
library is taking, and ordinary use of the language.

If you care to look at old threads (not so very old) in [comp.std.c++] you'll
find the one where Andrei argued for reasonable defaults for the new random
number generators, so that you'd not need a PhD to use them. It seemed to me
that his arguments were not understood.

One of the most useful things in Boost, boost::intrusive_ptr, is not in C++0x.

That's a shame.

And I think the reason is that it's simple and useful. It's not academic enough.
If it was just a lot more complicated and subtle and less practically useful,
so that it could be discussed for ages with no clear conclusion, always with
some new subtlety pointed out by someone, then I think it would be in C++0x.

Modules, ditto. They would be simple and practically useful. But unfortunately,
no modules, at least not this time.

That's what I'm missing the most in C++. It's kind of ridiculous having a
language designed for "programming in the large", without module support. So we
swing it by manually creating header files, manually adhering to various
conventions, manually tweaking things by employing compiler-specific
pre-compiled headers, all that stuff that should have been standardized and
automated and checkable by the compiler, or at least the build system.

Also missing among practical features, a standard way to disable some common
silly-warnings, I think that could help a lot for the practical use of the
language. In particular the silly-warnings about implicit conversion to bool,
warnings about unused argument or local variable (the latter isn't really so
much an issue because a conforming compiler should detect non-trivial
constructor and not warn in that case), and warnings about constant condition
expression in 'if' or other selection. As it is, without a standard way to avoid
diagnostics all kinds of compiler-specific means are brought to bear.

However, there are some good things.

Type deduction, as you write, is basically just good, although the way it's
designed lets you very easily access otherwise practically inaccessible types.
With 'auto' in the picture, no longer does it suffice to declare a type private
or protected. Anyone can 'auto' to declare a holder for the result of a
function, so e.g. that useful C++98 proxy you've designed can easily outlive the
expression where it was meant to exist, with its referent no longer valid...

Argument forwarding is decidedly good, I think.

With argument forwarding we can finally, /I believe/, haven't tried this with
C++0x compiler, create reasonable smart pointers that take care of creation, not
just destruction. And that opens a large new frontier. Really usable things.
It's very awkward to do this with macros, and there's a syntax issue, for
default construction. I started exploring that but didn't go very far (for
various non-technical reasons).

Function attributes, good. But I'm missing the one really useful attribute, the
one that says this function will never throw. An empty throw specification
"throw()" doesn't do quite the same, because it obliges the standard-conforming
compiler to add a catch clause in order to invoke std::unexpected; an attribute
would on the other hand enable the compiler to avoid adding that catch clause.
In particular this would enable the style I prefer, a 'bool throwX(char
const*)', without using compiler-specific means to suppress warnings.


Cheers,

- Alf

PS: I think this thread ideally would belong in [comp.std.c++], but few read
that group.

 

[Michael DOUBEZ]

I know I'm going to get flamed here, but I really feel like C++ is
just getting way too complicated to be as practical as I feel it
should (and could) be. Before you start, I've been doing C++
professionally for probably 12 years, it's easily my strongest
language, and I consider myself a "C++ programmer", not a programmer
of some other language. I'm pretty comfortable with probably 90% of
what's in C++98, and have played around quite a bit (and actually
rather enjoy) things such as template metaprogramming and other more
advanced applications of C++.

But looking at what's coming in C++0x, I'm starting to feel like it's
just going too far. It actually started with Boost. I mean I greatly
value the genericity and flexibility of the utilities that boost
provides, but honestly, every time I need a new class that Boost
provides, it takes me an hour just to figure out what the heck the
documentation is talking about. Even for things which SHOULD be
simple. The other day I needed a pool, I figured "hey I bet boost has
a pool". Sure enough it did, and after an hour I realized it was a
waste of time and I could have written the class I needed in about 5
minutes, so I did. As another example, look at the date time library
in boost. It's insane and it takes forever even to figure out how to
use it in the most basic ways. MPI is even more ridiculous, if you
can even come close to understanding how MPI and Lambda work, you
deserve a PhD in something, for real.

MPI and Lambda are not so bad if you are familiar with the problem they
solve.

Have you had a look at GIL ? It is terrible. I succeeded in using it and
was very happy with the result but I had to double my ration of caffeine
to keep up with the concepts, how they interact and how they were
implemented.

I'm getting off a little off topic talking about boost, but the
principle is carrying over into C++0x, albeit with basic syntax
issues. There are a few saving graces to C++0x, most notably I think
the type inference features being introduced are long overdue and
frankly pretty amazing. But rvalue references? I've tried explaining
these to FIVE different C++ programmers, and nobody has any idea what
I'm talking about. It's like I'm trying to teach them Haskell or
Hungarian, or something. But it sure doesn't sound to them like I'm
talking about C++. Concepts are almost as bad. I mean the intention
is in the right place, but that was the case with templates as well,
and I've actually quit TWO jobs over the fact that I had inherited
someone else's template code, and it was fundamentally ruined because
the person didn't understand how to correctly design large-scale
template libraries. In one case, after I quit I was told by a former
colleague that the company wrote into their coding standard that
templates were strictly forbidden from all future use, with the
exception that standard library templates could be used. Just that no
future template classes could be created.

My heart is and always has been with C++, but honestly if these trends
continue I might find myself honing my expertise in other languages in
the (near) future. C++ is still an amazing language if you're on a
team full of other people who have written a standards conformant C++
compiler, but in the real world where most of your colleagues are
average (by definition of the word average), it's becoming more
painful than it is enjoyable.

Agree? Disagree? Flame?

I agree in the sense that IMHO C++ is becoming more and more expert
friendly but I think it reflects the organization in the C++ community:
some write libraries with very elaborate stuff and MPL, others write
applications and use those libraries with the expressiveness they provide.

The problem is now a problem of communication between these two groups.
Typically Boost has a formal way of documenting (with Concepts ...)
which IMHO is useful for other library builders but not so much for
users who are looking for a solution and not necessarily the
architecture or the underlying idea of a tool.

From what I have seen in the software factory (in France), very few
people use templates and, if so, in a very limited manner. The questions
regarding C++ I saw in interviews (Looking for a job - hint, hint) were
all related to OOP and expert questions were related to patterns of the
GoF book (I even saw evaluation test still using the old headers).

All of that to say, yes modern C++ is very powerful and very difficult
to harness but the next standard provides many tools to overcome the
limitations of the language which helps in closing the gap between
library builder and user. Ideally, the users won't have to debug tons of
output for a deeply nested error but will have a clean static_assert
error and they won't have to understand the limitation of the language
that skewed the design or the possibilities of a lib.

 

[Juha Nieminen]

But rvalue references? I've tried explaining
these to FIVE different C++ programmers, and nobody has any idea what
I'm talking about. It's like I'm trying to teach them Haskell or
Hungarian, or something. But it sure doesn't sound to them like I'm
talking about C++. Concepts are almost as bad.

You don't have to know anything about rvalue references or concepts in
order to benefit from them.

Concepts help the compiler give you more understandable error
messages. Is that a bad thing? Rvalue references help making your code
more efficient. Is that a bad thing?

If it's not a bad thing, then who cares if the internal details are
complicated to understand? I don't understand how exceptions work
internally, but that doesn't stop me from benefiting from them. So why
should I care if the details are complicated?

If you don't like rvalue references because they are too complicated,
then the solution is rather simple: Don't use them. You can keep
programming exactly as you have done to this day. You don't need to
understand them. It's not like you would be forced to understand rvalue
references in order to program in C++0x. I honestly can't see the problem.

 

[Noah Roberts]

You don't have to know anything about rvalue references or concepts in
order to benefit from them.

Exactly. Unless you're writing a library that uses move semantics I'm
pretty sure you simply don't need to care what rvalue references are or
how they work. The rvalue reference solves an important problem for
library writers. For instance, you'll now be able to store uncopyable
objects in the standard containers because of this language feature.

Concepts help the compiler give you more understandable error
messages.

More than that I believe. The boost::concepts can do that. The
concepts in the new standard, as a feature of the language and not some
coding hack, allows you to write template code that will only activate
for types that represent the required concepts. In other words, you'll
be able to competently decide which template code to use based on the
concepts your type represents! This is a MAJOR benefit, especially for
library authors.

Although not everyone understands concepts in C++, everyone SHOULD.
Concepts are far from new and the entire standard library uses them.
They're just not possible to enforce by the language yet and when you
violate the documented concept interface of a type in the STL you get
template error vomit instead of something nice. The new language simply
takes something you've been using all along and makes it a feature of
the language.

If you don't like rvalue references because they are too complicated,
then the solution is rather simple: Don't use them. You can keep
programming exactly as you have done to this day. You don't need to
understand them. It's not like you would be forced to understand rvalue
references in order to program in C++0x. I honestly can't see the problem.

Exactly. The standard philosophy of C++ still stands: don't make anyone
pay for anything they don't need to use.

People complaining about these things should go talk to the people who
are behind why they are going in. Go sit down with Steven Wantanabe, as
I did, and have it explained to you why rvalue references are important.
Frankly, they're a mystery to me too but he was able to point out
several cases where all these "complex" language features will make
writing code easier.

I don't know what the complaint about boost::lambda is besides the fact
that it actually doesn't work that great. Unlike boost::bind, for
instance, it can't deal with smart pointers and the like. The new
lambda syntax going into the language is a might bit strange but I don't
have to use it.

Variadic templates fall into this category as well. The whole pack
thing is quite a change in perspective, but the template code that
results is a whole lot better than the preprocessor code required to
work around the language limitation that currently exists. Furthermore,
nobody has to use them.

I'll tell you what though, you're going to benefit from all of these
features in the form of very nice additions to the standard library.
The whole bind1st, bind2nd crap is GONE! Well, it's there, you can use
it, but there's much better in its place: bind(). Function pointers are
basically a thing of the past to be replaced by a function object that
can store and use any function that is callable with the arguments
supplied...no more undefined behavior because your void function pointer
points at a function returning an int.

The threading stuff is also a major improvement and relies upon at least
one of the features being complained about here: rvalue references.
Because threads are "movable" they can be stored in a container that can
hold movable objects. As I said, the new standard containers will.

So your really trying to toss out the baby with the bathwater. Ok, the
bathwater is gross and ugly to some people...but the baby will be loved
by most. If you don't want the bathwater, don't drink it.

 

[Kai-Uwe Bux]

But rvalue references? I've tried explaining
these to FIVE different C++ programmers, and nobody has any idea what
I'm talking about. It's like I'm trying to teach them Haskell or
Hungarian, or something. But it sure doesn't sound to them like I'm
talking about C++. Concepts are almost as bad.

[snip]
If you don't like rvalue references because they are too complicated,
then the solution is rather simple: Don't use them. You can keep
programming exactly as you have done to this day. You don't need to
understand them. It's not like you would be forced to understand rvalue
references in order to program in C++0x. I honestly can't see the problem.

That is _not_ the solution unless you program in solitude. As soon as you
are a maintenance programmer or have to deal with code of others, you have
to be fluent in the C++ _they_ use. That can include all the new features.

Related: code should not be regarded solely as a means of instructing a
computer. It is also a means of communicating with other programmers. In
that regard a language can fail by being overly complex. At some point, a
language can get so large that the investment it takes to familiarize
yourself with all features becomes too large to make (after all, there are
other things competing for my attention). But a language needs to be shared
in order to serve as a means of communication.


Best

Kai-Uwe Bux

 

[Zachary Turner]

You don't have to know anything about rvalue references or concepts in
order to benefit from them.

Concepts help the compiler give you more understandable error
messages. Is that a bad thing? Rvalue references help making your code
more efficient. Is that a bad thing?

If it's not a bad thing, then who cares if the internal details are
complicated to understand? I don't understand how exceptions work
internally, but that doesn't stop me from benefiting from them. So why
should I care if the details are complicated?

If you don't like rvalue references because they are too complicated,
then the solution is rather simple: Don't use them. You can keep
programming exactly as you have done to this day. You don't need to
understand them. It's not like you would be forced to understand rvalue
references in order to program in C++0x. I honestly can't see the problem.

The problem is, who's going to want to program in a language if they
know that only, say, 50% of the language is going to be accessible to
them at their IQ level? Why would the person not just pick another
language in that case, a language where they personally would feel
more productive since they know they're getting everything out of the
language that it has to offer?

It's like trying to get your grandmother to use Linux. It's more
powerful and she can do more stuff with it, but if the only thing she
can *figure out* how to do is click the Firefox icon, while in Windows
she can also figure out how to change her password and her desktop
wallpaper, then she's not going to use it.

The problem is that C++ markets itself as a mainstream language, a
language for the masses so to speak (where the masses is anyone who
wants to write code that is close to the OS level), yet ALOT of the
constructs it provides are almost solely of academic interest.

So then what happens? You get your C++ programmer who deep down would
love to to start a national C++ Bee (http://www.christiannewswire.com/
news/513588015.html) to see who can recite more of the C++ Standard
conducting all the job interviews (everyone knows there's 1 of these
guys at every company), and the guy who answers "no" when asked if he
understands r-value references doesn't get the job, because the next
guy answers "yes" and answers something that remotely resembles a
correct answer, and then when he gets the job he ruins the entire
product because he started sprinkling all these cool features all over
the code for no other reason than that they're advanced and cool, and
he thinks that using them everywhere will make people respect him more
because he's obviously smart. Another product destroyed....

Honestly, if 90% of the users of a language aren't going to understand
how to use something effectively, or for that matter AT ALL, it
shouldn't be in the language.

 

[Zachary Turner]

The problem is, who's going to want to program in a language if they
know that only, say, 50% of the language is going to be accessible to
them at their IQ level?  Why would the person not just pick another
language in that case, a language where they personally would feel
more productive since they know they're getting everything out of the
language that it has to offer?

It's like trying to get your grandmother to use Linux.  It's more
powerful and she can do more stuff with it, but if the only thing she
can *figure out* how to do is click the Firefox icon, while in Windows
she can also figure out how to change her password and her desktop
wallpaper, then she's not going to use it.

The problem is that C++ markets itself as a mainstream language, a
language for the masses so to speak (where the masses is anyone who
wants to write code that is close to the OS level), yet ALOT of the
constructs it provides are almost solely of academic interest.

So then what happens?  You get your C++ programmer who deep down would
love to to start a national C++ Bee (http://www.christiannewswire.com/
news/513588015.html) to see who can recite more of the C++ Standard
conducting all the job interviews (everyone knows there's 1 of these
guys at every company), and the guy who answers "no" when asked if he
understands r-value references doesn't get the job, because the next
guy answers "yes" and answers something that remotely resembles a
correct answer, and then when he gets the job he ruins the entire
product because he started sprinkling all these cool features all over
the code for no other reason than that they're advanced and cool, and
he thinks that using them everywhere will make people respect him more
because he's obviously smart.  Another product destroyed....

Honestly, if 90% of the users of a language aren't going to understand
how to use something effectively, or for that matter AT ALL, it
shouldn't be in the language.

Just to add one more thing, I'm not saying that these things like
concepts and r-value references aren't useful. I just don't think
they should be *in the language*. Designining the standard libraries
with them would be great since it would allow people to benefit from
them without introducing the inevitability that they will cause more
harm than good over the long run. I would argue that maybe even
templates have done more harm than good, I honestly have never
maintained a single usable code base where the original author used
templates. It's always a complete nightmare, even though I personally
understand templates perfectly.

Obviously the idea of implementing the libraries in a superset of the
language raises its own set of issues, but I don't think it's a
totally unsolvable problem. Maybe that's not even the best solution,
but I'm pretty sure that the current direction things are heading is
one of the *worst possible* solutions from a practical standpoint.

 

[Noah Roberts]

It's like trying to get your grandmother to use Linux.

My grandmother uses Linux.

 

[Matthias Buelow]

Exactly. The standard philosophy of C++ still stands: don't make anyone
pay for anything they don't need to use.

The "standard philosophy" rather seems to be: trade programmer time for
execution time. C++ has become so spectacularly unproductive for me, I
even have written ad-hoc interpreters to implement parts of an app in a
less bureaucratic language (a small dialect of Lisp, in that case) for
the simple reason that juggling with C++ only is so utterly unwieldy and
frustrating.

 

[Noah Roberts]

The "standard philosophy" rather seems to be: trade programmer time for
execution time. C++ has become so spectacularly unproductive for me, I
even have written ad-hoc interpreters to implement parts of an app in a
less bureaucratic language (a small dialect of Lisp, in that case) for
the simple reason that juggling with C++ only is so utterly unwieldy and
frustrating.

Whatever. Then stop using it.

 

[Juha Nieminen]

The "standard philosophy" rather seems to be: trade programmer time for
execution time. C++ has become so spectacularly unproductive for me, I
even have written ad-hoc interpreters to implement parts of an app in a
less bureaucratic language (a small dialect of Lisp, in that case) for
the simple reason that juggling with C++ only is so utterly unwieldy and
frustrating.

That kind of whining makes no sense.

There's no such a thing as the perfect programming language which is
optimal for all possible tasks. That's a physical impossibility.

Many fanatics of some languages will boast how superb their pet
language is and how it can be used for basically anything, but usually
when you start studying the language in question, you always find
shortcomings and things which it's not very suited for.

Bashing a language for the reason that it's not the optimal language
for all possible tasks is just stupid.

 

[Juha Nieminen]

That is _not_ the solution unless you program in solitude. As soon as you
are a maintenance programmer or have to deal with code of others, you have
to be fluent in the C++ _they_ use. That can include all the new features.

Related: code should not be regarded solely as a means of instructing a
computer. It is also a means of communicating with other programmers. In
that regard a language can fail by being overly complex. At some point, a
language can get so large that the investment it takes to familiarize
yourself with all features becomes too large to make (after all, there are
other things competing for my attention). But a language needs to be shared
in order to serve as a means of communication.

Many people benefit greatly from the new features. Some people might
require extra studying to understand these features.

Your argument basically says that it's better to deny the former
people the useful tools for the sake of the latter people.

I can't say I agree with that.

 

[Juha Nieminen]

The problem is, who's going to want to program in a language if they
know that only, say, 50% of the language is going to be accessible to
them at their IQ level? Why would the person not just pick another
language in that case, a language where they personally would feel
more productive since they know they're getting everything out of the
language that it has to offer?

Are you seriously suggesting that C++ should be dumbed down so that
people with lower IQ can use it?

I'm not even sure how I should understand that.

 

[Matthias Buelow]

There's no such a thing as the perfect programming language which is
optimal for all possible tasks. That's a physical impossibility.
Agreed...

Many fanatics of some languages will boast how superb their pet
language is and how it can be used for basically anything, but usually
when you start studying the language in question, you always find
shortcomings and things which it's not very suited for.
Bashing a language for the reason that it's not the optimal language
for all possible tasks is just stupid.

Yes.. I haven't tried to "bash" C++ for not being optimal. I was merely
substantiating the OP's point that C++ is getting too complicated, from
my perspective. IMHO, C (or the early, much simpler C++) isn't a vehicle
suitable for building a complex multi-paradigmatic language upon, like
C++ is trying to be. It's all hacks and horrible ad-hoc voodoo. C is,
despite quite a few sores and tumours, a relatively elegant language for
what it was designed to be. The early C++ was a working add-on hack,
neither particularly elegant, rather quirky but practical enough that
people picked it up. Modern C++, however, is an abomination and has lost
the point a long time ago.

 

[Michael Mol]

The problem is, who's going to want to program in a language if they
know that only, say, 50% of the language is going to be accessible to
them at their IQ level?  Why would the person not just pick another
language in that case, a language where they personally would feel
more productive since they know they're getting everything out of the
language that it has to offer?

There's a major difference between IQ and ability to learn a language--
and that difference is motivation. The type of person you're warning
about is the type of person who's not actually motivated to learn to
use the tools available to them effectively.

As far as choice goes, if they actually *have* a choice in the
language they're going to use, then they should make a choice based on
their project's requirements. There have to be at least 50 mature
general-purpose languages out there, and hundreds more which are
targeted to specific problem domains.

The problem is that C++ markets itself as a mainstream language, a
language for the masses so to speak (where the masses is anyone who
wants to write code that is close to the OS level), yet ALOT of the
constructs it provides are almost solely of academic interest.

As quantifiers go, "a lot" is a pretty poor punt. As I've used C++,
I've discovered that a lot of things that I thought of as academic
turned out to have very practical uses. But then, that's the way it
normally goes, isn't it? Something has to be studied before it
becomes practical.

[ snip straw man anecdote ]

Honestly, if 90% of the users of a language aren't going to understand
how to use something effectively, or for that matter AT ALL, it
shouldn't be in the language.

90% of all users aren't competent enough to truly understand the
language they're using, be it Haskell, PHP, C++, C, ANSI BASIC or a
four-function calculator with an M+ button. And, again, it comes down
to an issue of motivation and how much you care about effectively
writing good code.

(Google: "90% of everything is crap")

 

[Juha Nieminen]

Modern C++, however, is an abomination and has lost
the point a long time ago.

Yet people use it to write elegant, efficient and easily maintainable
code.

Why do some people have the obsession that

tons of features = you must understand all of them to use the language

?

 

[Noah Roberts]

Yet people use it to write elegant, efficient and easily maintainable
code.

Why do some people have the obsession that

tons of features = you must understand all of them to use the language

?

It's an abomination I tells you!!! It's too complicated!!! Really, it
is!!!

Don't expect me to expand on that, it's all I gots.

 

[Kai-Uwe Bux]

Many people benefit greatly from the new features. Some people might
require extra studying to understand these features.

Your argument basically says that it's better to deny the former
people the useful tools for the sake of the latter people.

I can't say I agree with that.

a) That you do not like the conclusion of an argument does not make it
invalid

b) You actually misrepresent what I said. All that follows is that
complexity has drawbacks. Whether the advantages outweigh the costs is a
different matter altogether. But what does not fly is pretending the costs
do not exist. (And this is what you did in the part you snipped and that I
responded to.)


Best

Kai-Uwe Bux

 

[Zachary Turner]

  Are you seriously suggesting that C++ should be dumbed down so that
people with lower IQ can use it?

  I'm not even sure how I should understand that.

I'm suggesting that they should be honest about who their target
audience is. If the intended audience is academia, they're free to do
whatever they want with it. Make it as complicated and impractical as
humanly possible. But if they're going to claim that it's a language
for use in solving mainstream, practical problems, then that's what it
needs to be. And currently, it's not anywhere close to that. It's no
longer the best at anything really, except perhaps at interfacing with
legacy C/C++ code. If you want to write code that's in a HLL and
still close to the OS you can use D now. Indeed, Andrei Alexandrescu
is even a big fan of D now. (I have no idea what his stance is on C++
anymore, he could very well still love it). But what exactly *is* the
compelling use case for C++ anymore? For all its complexity, it
should at the very least offer a clear advantage in *something*, and I
honestly don't think it does anymore, and furthermore that it's
accelerating away from such a goal. The only possible advantage it
might offer anymore is that its standard libraries are reasonably
mature, but any language can achieve the same thing given enough time,
and this still of course assumes that you can figure out how to use
the standard libraries.

I'm also noticing that you've sidestepped the real question in every
single one of your responses, and instead chosen to respond with
subtle suggestions that I might, perhaps, be too stupid to understand C
++'s awesomeoness. To which I would say that first of all, you should
try to answer the real question (in particular, why should someone
bother using a language for which the learning curve is unnecessarily
high compared to the productivity curve, when you can achieve exactly
the same things in other languages much simpler), and second of all,
when you have to convince a large number of people (and believe me, I
don't think I'm the only one) who have been proponents of C++ for a
very long of C++'s long-term position in the world of programming
languages, then perhaps it's time for some inner reflection. Instead
of just denying everything people are saying without giving it some
actual thought, think about what people are saying.