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

On Mar 19, 12:16*pm, Noah Roberts <n...@nowhere.com> wrote:
> Matthias Buelow wrote:
> > Noah Roberts wrote:
>
> >> 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.
>
> Whatever. *Then stop using it.

See, this is exactly the attitude that fails so, so hard and is
unfortunately so, so easy to fall victim to. Are you seriously
suggesting that there is no room for constructive criticism, and that
we should instead just take everything we're given with glowing eyes
because They have graced us with it? Ok, maybe the guy you were
responding to was a little extreme in his criticism, I don't think C++
is "spectacularly unproductive", but it sure as HECK isn't
"spectacularly productive", which ideally is what you want out of a
language.

The reason I bring this issue up at all is because I *do* love C++,
and I would like to be using it 10 years from now. However, if I want
a language that gives me warm fuzzies when I do something that's
incredibly elegant, yet incredibly hard to understand for the average
programmer, I'll program in Haskell (which tbh is where I might end up
going after I abandon C++). But at least there they make no mistake
about their target audience. It's for academia, by academia,
literally. C++ is caught in this purgatory state where it's
pretending to be for the mainstream, yet most of the new things that
get introduced are incredibly academic in nature and there is no hope
of an ordinary programmer understanding it. And every time something
practical that actually MAKES SENSE and is easily understandable is
proposed, it gets shot down. See Alf's response near the top of this
thread, or see Herb Sutter's proposal to remove the export keyword
from the language (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/
2003/n1426.pdf). Another perfectly reasonable and practical
suggestion, shot down because it lowers C++'s academia score.

Zachary Turner

On Mar 19, 11:12*pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> 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.)

The point is, that with the new standard the added/changed stuff makes
the language *use* *less complex*. Compilers possibly will sweat a
little more, but on the end user end you *lose* many awkward tricks or
ambiguity to be replaced with way clearer and easier things.

A few examples:

- threads: memory model, library. Single threaded environment not
effected. MT had to deal with issues "in the wild", now you have
strict guarantees and portable lib in the box.

- auto: finally kill the redundancy and verbosity just to tell the
compliler it already should know

- concepts: as template user you get clear error message on bad use,
and clear documenttion of the intent;
as template writer you can tell the intent in code instead of leaving
to vague comments. as bonus you finally can create defaults,
alternatives, those writing templates have a huge list of pain -- now
mostly gone

- rvalue refs: as library user you can benefit from move semantics
without doing anything. as tweaker remove worries about extra copies.
+bonus, can collect extra types

- bind: nuff said

- more smart pointers, collections: no more hunt for external libs for
stuff you likely want

pasa@lib.hu

On Mar 19, 11:17*pm, Zachary Turner <divisorthe...@gmail.com> wrote:
> I'm suggesting that they should be honest about who their target
> audience is.

Who is "they"?

C++ was thought complex from the start, it sure was at first standard.
The world invented VB, java, C# to be lighter on programmers and
learning curve. (Read Joel Spolsky on javaschools for the result... )

As of now C++ is still considered the second best pick for any
particular task, and beign multi-paradigm you can get way better
results than with a fast pick.
It ceratainly needs more brains on the programmer and more time to
master. If you have bad or lazy programmers, forget it. (industry
shows that those wreak havoc in any language, so its better to just
not use them...)

>*If the intended audience is academia, they're free to do

No, the intended audience is bright pragmatic programmers. With a
calling too. Those who are not afraid to read a few books, and pay
attention to learning instead of just experimenting in the editor
until something compiles and "looks like work".

I.e. terms like "lvalue" and "rvalue" were present IIRC even in the
K&R C book. and reference was in CFront 1.0. So what can be the the
problem understanding rvalue reference and lvalue reference? Guess
those without clue never understood the difference of rvalues, and
coded bugs wherever it mattered.

> 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 it is too. Then if it is not fit for your field, don't use it. Or
if you like the '98 version, stick with that, the compilers will not
disappear, and most have switch to select the acting rules.

>*And currently, it's not anywhere close to that. *It's no
> longer the best at anything really,

Was it ever? And nowadays with more frameworks, toolsets, the pick is
even less based on language but the libraries, ready components and
stuff like that. For greenfield projects.

And where you contnue the existing job... you're stuck with most
elements anyway.

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

So then what? People make D, E, F -- should that seal C++? And leave
it as it is, not addressing the many problems and needs of the users?
Hope you don;t claim it is not used and there is shortage of projects
that will need maitainance further.

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

Honestly, your posts after the first indeed leave the impression of
empty flame and closed mindset. And there's nothing much to address,
in taste-based stuff. You have the right to not like C++ or think it
is [whatever]. Or flame it or bash it.
If you mean your examples seriously however -- you need to go down to
details and explain what is really YOUR problem. As those you picked
are quite straightforward. Not liek two-phased lookup, or
similars.

>*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,

Inesrting 'why' before false statements will not form sensible
questions.

And the whole approach is fishy -- many people already know C++ and
used it for a deal of time -- so can pick up the difference easily and
enjoy.
Language and environment for a particular project is decided using
many factors -- but not from the big bang. I heard of 0 cases where
language were decided and company hired greenies all starting to learn
the decided language. Instead you either have the knowledge in house
or hire it. And beyond very trivial scope the learning curve of the
language itself is little compared to the buiness logic/the real
task.

If only language learnability counted we would all use nothing but
scheme, would we? Or maybe python. (and yeah, I suggest pick thse,
or anything if fits).

The advantage of C++ over many others is being multi-paradigm, so it
gives you more tools to cover the task with optimal ones. i.e. with
java you can learn faster, but if your task does not match very
closelt "the one JAVA WAY", you get hosed very soon, and will suffer
for the rest of your time. Whatever good programmers you get early or
late.

> when you can achieve exactly
> the same things in other languages much simpler),

That depends quite much. A big project can have many different
"things", that are easy to cover by many languages -- and you'll have
the problem unable to put together.
Or pick up such new, non-fitting stuff in V2.5 and later...

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

Huh? The C++ standard is being made from like '93 and the process is
open to everyone. Whoever have something to say (add, remove, modify)
can do it in the committee directly or submit as proposal, or talk in
forums (comp.std.c++, this, this.moderated has several dozens of
people with drect influence, and pay attention to input.

pasa@lib.hu

On Mar 19, 11:28*pm, Zachary Turner <divisorthe...@gmail.com> wrote:
> > Whatever. *Then stop using it.
>
> See, this is exactly the attitude that fails so, so hard and is
> unfortunately so, so easy to fall victim to. *Are you seriously
> suggesting that there is no room for constructive criticism,

Where is the *constructive* part of criticism? 'c++ is complex' is
not that. Especially as it is a fact of life that will not go away:
it applies to C++98 and back-compatibility was always the top
priority.

That one is really 'take it or leave it'. But we're still listening
anything constructive, how to make stuff better?

> I don't think C++
> is "spectacularly unproductive", but it sure as HECK isn't
> "spectacularly productive", which ideally is what you want out of a
> language.

I know people and projects where it worked very well, also others
falling in trap of some seemingly "faster" tech and failed to
complete.

It is engineering task to chose the tools/language correctly.

> The reason I bring this issue up at all is because I *do* love C++,
> and I would like to be using it 10 years from now. *However, if I want
> a language that gives me warm fuzzies when I do something that's
> incredibly elegant, yet incredibly hard to understand for the average
> programmer,

Will you be happier if we post a statement in NY Times that "C++ is
NOT for the average programmer"? IMO programming in general is not
for the average programmer. I mean it. This profession stinks big
time, and shows no signs of clearing up. At least in some fields
programming should be tied to kind of licence and related exams (as
goes for doctors, architects, etc...). 80+% of programmers I saw IRL
are pure danger to leave working on their own.

And yes, C++ is even more demanding. And leaves more dangers too, many
cases of UB, etc.
Let's hope in the next 10 years at least some separation happens, and
who remains with C++ will be the fittest.

> C++ is caught in this purgatory state where it's
> pretending to be for the mainstream, yet most of the new things that
> get introduced are incredibly academic in nature and there is no hope
> of an ordinary programmer understanding it.

???
http://en.wikipedia.org/wiki/C%2B%2B0x
has a summary of changes, please cut the list and mark the bullets
that fit that description. Then we may have some constructive
conversation, also with some figure of the infestation percentage.

>*And every time something
> practical that actually MAKES SENSE and is easily understandable is
> proposed, it gets shot down.

Can you list *worked out* proposals that were just dismissed without
justification?

> See Alf's response near the top of this
> thread, or see Herb Sutter's proposal to remove the export keyword
> from the language (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/
> 2003/n1426.pdf).

Well, export is a sad story, but how many like that we have compared
to all the proposals? but it hardly fits the above description still.

I didn't follow intrusive_ptr, but would guess there were pretty good
reasons it didn't make it, "every time" dismissing "anything that
makes sense" looks like a gross statement, and you need a fat list to
even start looking supported...

>*Another perfectly reasonable and practical
> suggestion, shot down because it lowers C++'s academia score.

Just thinking people in the committee, how academy gets in the
picture, really.

pasa@lib.hu

On Mar 19, 10:28*pm, Zachary Turner <divisorthe...@gmail.com> wrote:
> On Mar 19, 12:16*pm, Noah Roberts <n...@nowhere.com> wrote:
>
> > Matthias Buelow wrote:
> > > Noah Roberts wrote:
>
> > >> 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.
>
> > Whatever. *Then stop using it.
>
> See, this is exactly the attitude that fails so, so hard and is
> unfortunately so, so easy to fall victim to. *Are you seriously
> suggesting that there is no room for constructive criticism, and that
> we should instead just take everything we're given with glowing eyes
> because They have graced us with it? *Ok, maybe the guy you were
> responding to was a little extreme in his criticism, I don't think C++
> is "spectacularly unproductive", but it sure as HECK isn't
> "spectacularly productive", which ideally is what you want out of a
> language.
>
> The reason I bring this issue up at all is because I *do* love C++,
> and I would like to be using it 10 years from now. *However, if I want
> a language that gives me warm fuzzies when I do something that's
> incredibly elegant, yet incredibly hard to understand for the average
> programmer, I'll program in Haskell (which tbh is where I might end up
> going after I abandon C++). *But at least there they make no mistake
> about their target audience. *It's for academia, by academia,
> literally. *C++ is caught in this purgatory state where it's
> pretending to be for the mainstream, yet most of the new things that
> get introduced are incredibly academic in nature and there is no hope
> of an ordinary programmer understanding it. *And every time something
> practical that actually MAKES SENSE and is easily understandable is
> proposed, it gets shot down. *See Alf's response near the top of this
> thread, or see Herb Sutter's proposal to remove the export keyword
> from the language (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/
> 2003/n1426.pdf). *Another perfectly reasonable and practical
> suggestion, shot down because it lowers C++'s academia score.

I'm sorry but all your comments about new features and/or changes in
the next standard revision (C++0x) being only targeted at academia are
just ridiculous. I use C++ in my job, as far as I can see every new
proposed feature/change is not motivated by research papers in
programming language theory. The only new feature that remotely comes
close to this is the new Concept system but they where only part of
researching a solution to a common problem, which is not even a
problem unique to C++ & templates, it is a more general problem of
providing bounded quantification of parametric polymorphism where the
method used to implement parametric polymorphism in this case is
templates. .NET generics provide a mechanism to bounded quantification
as does Haskell, it is a necessity not a novelty. These features are
not a new idea that is being tried out just for the sake of it.

snk_kid

Zachary Turner wrote:
> Are you seriously
> suggesting that there is no room for constructive criticism

Well, feel free and go ahead.

Personally I didn't find that post very constructive. It didn't have
any suggestion on how to improve the situation. It was just whining.

Juha Nieminen

Zachary Turner wrote:
> 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.

The main problem in your argumentation is that you make it sound like
the new features make using the language more complicated. You have not
presented any reason or evidence of this whatsoever. Your only evidence
seems to be "there are more features than before". In other words, you
are simplistically equating "more features" with "more complicated to
use", without even trying to explain why these two things would go hand
in hand.

Since one of the goals of the new features is to make the language
easier to use, you are basically implying that they are wrong, that the
new features do not make the language easier to use, but harder. Again,
you have presented absolutely no arguments or evidence of this
whatsoever. Again, you seem to naturally assume that "more features"
equals "more complicated to use".

Just as a concrete example: The new 'auto' feature is being added to
make it easier and simpler to write code. It seems that, according to
your logic, because this is an additional new feature, it makes using
the language more complicated. Care to explain how the 'auto' feature
makes writing code more complicated, as opposed to its actual goal,
which is to make writing code easier and simpler?

As long as you don't give convincing arguments about why the new
features make using the language harder, I don't think your point has
any basis.

If you don't want to use C++ because it's "too complicated" in your
opinion and has "no advantages over other languages", then by all means
don't use it. There are tons of languages out there. Feel free to choose
whatever you want. But don't start bashing C++ based on no evidence,
only on the really simplistic assumption that "more features" equals
"more complicated to use".

Juha Nieminen

Matthias Buelow wrote:
>
> 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.

But you don't have to bother with the bits you find too complex.
There's nothing to stop you sticking to the subset you understand.

I'm currently helping a C team transition to C++ and that's what we're
doing: small steps.

--
Ian Collins

Ian Collins

Ian Collins <ian-> writes:
>But you don't have to bother with the bits you find too complex.
>There's nothing to stop you sticking to the subset you understand.

Except from the fact that professional programmers more often
have to modify existing code than to write new code. This
means that a professional programmers has to read code more
often than he has to write code. The authors of the code he
has to read usually will not know which bits he finds too
complex, so they can not avoid them.

»C++ is already too large and complicated for our taste«

(This message is signed by a group of names including
»Bjarne Stroustrup« and was posted to Usenet as

From: (Bjarne Stroustrup)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: C++ Language Extensions
Message-ID: <>

The current C++ specification has about 700 pages, but one
needs to know the C specification it is based upon, too.
This C specification from 1990 is not easy to obtain, and
it has about 300 pages. So alone the specification of C++
has about 1000 pages (plus parts of other ISO specifications
needed to understand some wording). Reading specifications
will not educate about common usage, such as template
metaprogramming or Doxygen - which has to be learned in
addition to the language fundamentals.

Stefan Ram

(Stefan Ram) writes:
>>But you don't have to bother with the bits you find too complex.
>>There's nothing to stop you sticking to the subset you understand.
>Except from the fact that professional programmers more often
>have to modify existing code than to write new code.

Maybe this is, why someone wrote »Today's C++ programs will be
tomorrow's unmaintainable legacy code.«

Stefan Ram