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

Discussion in 'C++' started by Zachary Turner, Mar 19, 2009.

  1. 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, Mar 19, 2009
    #21
    1. Advertisements

  2. Zachary  Turner

    pasa Guest

    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, Mar 19, 2009
    #22
    1. Advertisements

  3. Zachary  Turner

    pasa Guest

    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...)
    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.
    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.
    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.
    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.
    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. :)
    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.
    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...
    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, Mar 19, 2009
    #23
  4. Zachary  Turner

    pasa Guest

    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 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.
    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.
    ???
    http://en.wikipedia.org/wiki/C++0x
    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.
    Can you list *worked out* proposals that were just dismissed without
    justification?
    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...
    Just thinking people in the committee, how academy gets in the
    picture, really.
     
    pasa, Mar 20, 2009
    #24
  5. Zachary  Turner

    snk_kid Guest

    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, Mar 20, 2009
    #25
  6. 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, Mar 20, 2009
    #26
  7. 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, Mar 20, 2009
    #27
  8. Zachary  Turner

    Ian Collins Guest

    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, Mar 20, 2009
    #28
  9. Zachary  Turner

    Stefan Ram Guest

    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, Mar 20, 2009
    #29
  10. Zachary  Turner

    Stefan Ram Guest

    Maybe this is, why someone wrote »Today's C++ programs will be
    tomorrow's unmaintainable legacy code.«
     
    Stefan Ram, Mar 20, 2009
    #30
  11. A professional C++ programmer who has to modify existing programs and
    doesn't know the language well enough to do so?

    I don't know what you call that, but I call it incompetence. You
    should know your field of expertise, especially if you do it as a
    profession.

    Are you going to tell, for example, a TV repairman that TVs are
    internally too complicated and thus no TV repairman should be expected
    to be able to do their job?
     
    Juha Nieminen, Mar 20, 2009
    #31
  12. Zachary  Turner

    Stefan Ram Guest

    Yes, to use C++, one needs to know the language in
    the extend it is used in the field, but can not
    just select some »easy« parts of it. That was what
    I wrote.
    In fact, when a TV is broken, often, I believe,
    the repairman will not try to understand what
    actually is wrong, but either suggest to buy a
    new one or swap each of a few modules until it
    works again. But this discussion about TVs
    distracts from C++.
     
    Stefan Ram, Mar 20, 2009
    #32
  13. In the process, maybe this professional might learn something useful.
    "Hmm, perhaps I could use these so-called rvalue references to make this
    old library of mine more efficient and easier to use."

    That's a bad thing? Some people certainly make it sound like it is.

    I don't think anybody has denied that the C++ language is large and
    with lots of features, some of which are complex to understand and fully
    utilize. However, it can be reasonably argued to what extent this
    hinders the usability of the language.

    IMO equating "tons of features" with "is complicated to use" is too
    simplistic. That same equation could be used to argue that a basic
    command-line version of linux with no GUI is easier and less complicated
    to use than a full graphical version with a fancy window manager and
    tons of software. The latter version will undoubtedly have a lot more
    features (especially since it will usually be a pure superset of the
    former), but that doesn't automatically mean it's harder to use. Usually
    it means the exact opposite.
     
    Juha Nieminen, Mar 20, 2009
    #33
  14. Zachary  Turner

    Noah Roberts Guest

    Exactly. I'm just sick of the crying. Anyone that is going to reply to
    a set of statements explaining why these constructs are necessary and
    helpful with, "Waaaa, I had to write lisp in C++ because I couldn't
    think of a better way," and expects people to care...needs to do a lot
    more thinking on the matter. The poster didn't bother to respond to a
    single point I made and apparently can't see past the horizon of their
    own inability.

    Last thing I want is for C++ to be designed to cater to people who do
    nothing but wine. Use some other language, PLEASE.
     
    Noah Roberts, Mar 20, 2009
    #34
  15. Zachary  Turner

    Noah Roberts Guest

    Quite frankly, the fact that people have to maintain existing C++
    programs doesn't work that well for those claiming we should keep these
    new features out of C++. The proposed features, and the ones people are
    complaining about, are proposed because they simplify things. The kinds
    of preprocessor garbage necessary to fake the existence of variadic
    templates for instance is just horrid, horrid stuff. In my place of
    work I am *the only one* that understands it. The addition of variadic
    templates will require some learning and some new terminology but vastly
    simplifies the problem so that people WILL be able to maintain such code.

    The same applies to the other features people are complaining about
    here. As I posted quite a while ago (with the only reply being some
    crap about needing to write lisp) the new language and library solves
    many of the issues that C++ developers face that make their lives
    tougher than need be and their code less maintainable.

    So really, you guys should get off this particular soapbox...it stands
    against you.
     
    Noah Roberts, Mar 20, 2009
    #35
  16. Zachary  Turner

    Noah Roberts Guest

    Yup. In reality this fear of the new features is nothing BUT fear. As
    is true of most fear, it's based on ignorance. People just scared of
    change without really understanding why the change is being made to
    begin with.

    People need to go study what's being proposed and why instead of just
    looking at a few blogs and running away in terror.
     
    Noah Roberts, Mar 20, 2009
    #36
  17. It's called 'experience'. 25 years of optimising the shovel and you want
    us to believe that, all of a sudden, the ladder has been produced?
     
    Matthias Buelow, Mar 21, 2009
    #37
  18. It's also based on experience. It's quite possible that at your
    current and past jobs, all the other programmers you've worked with
    and whose code you've had to maintain were just like you. If so your
    opinion is understandably biased and you haven't seen the other side
    of the fence that alot of us have seen. Trust me, I've looked at
    what's being proposed and my post is most certainly not based on
    ignorance, lol. If all disagreements to your opinion you simply chalk
    up to ignorance, then you need to take a step back and reflect a
    bit.

    Alot of the things in the new standard are flat out good, as others
    have pointed out. Threads, initializer lists, type inference, all
    examples of things that are just good any way you look at it. Oh, and
    unicode is probably the biggest win of all.

    Concepts I'm on the fence about. Obviously I understand what they're
    for, why they're being introduced, and in general why they're
    awesome. I think however, that like most other things, the library
    writers will get them right and most other people will get them wrong,
    making them more of a PITA than anything else. Honestly a lot of
    people can't even figure out how to correctly use (runtime) asserts, I
    have no reason to think this will be any different.

    Constructors being allowed to call other constructors. Cool, not
    earth-shattering, but I guess this is handy.

    Typed enums. Another pure win, these are long overdue.

    changes to 'explicit' keyword. Most people I know dont even
    understand what the purpose of explicit in its current form. This is
    a change almost exclusively for library writers.

    Unions. They should have just deleted unions from C++, not enhanced
    them.

    I'm not crazy about variadic templates, I get the use case, and it's a
    template lovers dream, but the normal programmer actually isn't a
    template programmer believe it or not. Overall I think these will end
    up being used almost exclusively by library writers, with occasional
    exception.

    Type traits are for library writers, in fact metaprogramming in
    general is for library writers, and even that's arguable (in theory I
    guess a lot of the changes in C++0x will reduce the need for
    metaprogramming). Metaprogramming is awesome, don't get me wrong, but
    only if I'm the person doing it. There is no way I want to look at
    someone else's metaprogramming code.

    Rvalue references. Mostly for library writers, and micro-
    optimizations for the normal programmer, assuming of course they
    understand them.

    All in all, alot of C++0x is win, as I said in the original post. But
    the stuff that is for library writers, leave it at that. As crazy as
    it sounds, what I would really have liked is if the language forked
    into a normal version and an "extended" version, such that code
    written in the extended C++ could almost always be organized such that
    the "extended" features were limited only to CPP files. This way
    normal C++ could make use of libraries written in extended C++. I
    like the features, what I DON'T like is the fact that I'm going to
    have to work with other people who are going to try and use them. I
    know it's shocking, but your average C++ programmer *really* cannot
    even figure out how to use templates effectively. And if most of my
    time is going to be spent toiling over terribly written code, it's
    much more pleasant to just find a different language.
     
    Zachary Turner, Mar 21, 2009
    #38
  19. Zachary  Turner

    Michael Mol Guest

    I don't see your point. There are plenty of terrible programmers out
    there. There are *no* perfect programmers out there. How does a
    feature not being intuitive first-year programmers support not having
    it in the language to begin with? Where I work, when I don't
    understand a bit of code, or can't resolve a bug, I call a coworker
    over and have him take a look. The next time (or perhaps the time
    after that, if it's tricky), I'll know what's what. That's how I went
    from being a first-year programmer to something perhaps a bit better.
    Your complaints make it sound like you don't care for library writers,
    and don't think features helpful for writing libraries should be in
    the language. You realize that if it weren't for the library writers,
    we wouldn't even have the STL. Heck, without library writers, any non-
    trivial program you've seen would likely qualify for TDWTF. Heck,
    without library writers, the definition of "non-trivial" would slide
    back to what it was before I was born...
    That completely breaks templates, as your template function bodies
    typically reside exclusively in header files which the preprocessor
    dumps into your cpp file before subsequent compilation stages.
    You haven't been asking for a fork. A fork implies that two instances
    of a project can grow in different, incompatible ways. What it
    *sounds* like you're asking for is pegging the C++ standard at a
    version with features your coworkers already understand. If you're
    worried about having to rework shoddy source code, then I suggest that
    finding a different language won't help; You either need to put
    yourself in a work environment where that doesn't happen frequently*,
    or you need to get out of the software field entirely. There will
    always be programmers who write shoddy code in every language with
    more than one user, and as long as you look at code someone else
    wrote, you risk interacting with their code.

    This is a problem universal to the software industry, not one specific
    to C++.


    * Judging by their signatures, I'm certain that many folks in c.l.c++
    have done this by working for themselves...
     
    Michael Mol, Mar 21, 2009
    #39
  20. Zachary  Turner

    jacob navia Guest

    Some people here argue that C++ is not overly complicated.

    I am reading "C++ Templates, the complete Guide". There,
    the authors say (page 15)

    "The rules for this decision may become rather
    complicated even without templates. In this section we
    discuss overloading when templates are involved. If
    you are not familiar with the basic rules of overloading
    without templates please look at Appendix B, where we
    provide a reasonable detailed survey of the overload
    resolution rules".

    Great. That Appendix is 12 pages long! And it is not
    complete of course!

    Every C++ programmer *must* know those rules but maybe
    1% of them know the WHOLE set of rules because the human
    mind is not adapted to absorbing tons of programming trivia.

    THEN, it is obviously the task of the maintenance programmer
    to debug all those cases where the byzantine rules go
    completely in other direction that the poor programmer
    intended, when some new code using indirectly those
    overloaded functions is written, 2 years AFTER the original
    programmer left.

    The great majority of C++ programmers doesn't know *exactly*
    what are they doing when do a simple thing like overloading
    a function...

    Is this really necessary?

    Now, look at this "concept" concept again. (Sorry but I find
    no other way of saying it)

    Behind it is the need to declare a set of types so that
    template arguments can be checked by the compiler. OK.

    But wasn't *inheritance* supposed to define this stuff?

    If you make a standard "super-class" that describes a
    concept, wouldn't it be necessary just that your class
    INHERITS from that super class to be cleanly checked
    in the template argument list? Why is it necessary to
    introduce YET ANOTHER huge construct?
     
    jacob navia, Mar 21, 2009
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.