Why would I learn C++11, having known C and C++? | Hacker News Reader

Why would I learn C++11, having known C and C++?

programmers.stackexchange.com

11 pointsekm218 comments

The "I know enough already" attitude is exactly what I look for in an interview. If I find it, it's a "no hire".

Never settle for the average.

  > Never settle for the average.

Now that is advice that doesn't scale.

The title reads as if the questioner is genuinely interested in C++11, but from his comments it's clear that he only sought an outlet to rant.

That the accepted answer is 'learn C++11 to get a job, if necessary' speaks volumes.

Rather mercenary and uncurious attitude to take towards learning a programming language.

I mess with Clojure because I find it interesting, not because I think it'll help me cling to a paycheck.

I'd never knowingly hire someone who thought like that.

There are some languages—Lisp, Prolog, Haskell, maybe Mozart or whatever will fill that niche—which the curious ought to explore because they shape the way you think. But C++ is not one of them. It's yet another imperative single-dispatch OO language, like Java or C# but for masochists (and reams of legacy code that wasn't even exception-safe don't help). All the reasons to bother with it are practical ones focusing on its low-overhead runtime for certain niches.

Either you mistakenly believed I was speaking about C++11 specifically and/or you didn't read the accepted answer/response in the Stack Overflow thread.

The "accepted answer" was in a nutshell, 'Learn C++11 if it will get you a job or let you keep your job'.

I don't care if people find C++11 more or less interesting than Lisp, Mozart, Agda, or Dylan. That's not the point I was making.

The point is that anybody that bases what they learn purely in terms of "minimum effort necessary to keep my job" is not someone I will ever knowingly hire.

Also note that the answer you refer to doesn't say to learn language X if and only if it will let you keep a job/get you a job. It refers specifically to whether one should learn C++11. It says nothing at all about the myriad of fun and interesting languages out there that are worth learning for the sake of learning, of which C++11 might not be one depending on ones world-view.

By now it's about impossible to learn every language and platform. I prioritize by interesting and mind-bending, and at a glance, C++11 is not markedly better along these dimensions, which leavers it near the bottom of the list—unless somebody is going to pay me because I chose to defer learning everything more rewarding. I don't apply this reasoning to every language (hell, I lurk on LtU), just the most pedestrian and painful ones.

I'm not explaining myself clearly. Let me make this explicit.

Things that are NOT important to me:

1. Knowing every programming language and platform

2. Wanting to know every programming language and platform

3. What programming languages and platforms you think are most important to learn

4. Why you don't like C++11 or think it's not worth learning.

Things that ARE important to me:

1. Natural curiosity in those I work with

2. NOT working with people who are lazy and only do the bare minimum to keep a "good enough" job

The problem is that the choice of language to learn next is not signal for any of those points. With so many languages and platforms, one has to prioritize based on something. Job prospects is a perfectly fine criteria, even for someone who is curious and not lazy. It's a signal for pragmatism, and that's it.

C++ is not for masochists, it is for developers with a proper CS background that want to implement software with high performance and low resources usage, using a multiparadigm language.

It could be better and is full of warts, but there is no other language at the moment that could replace C++ for native coding.

Go is too few abstractions and D is still catching up to the TDPL specification. Both lack the amount of tooling that C and C++ have at their disposal.

Just curious -- what do you mean by Go having too few abstractions?

- no enums (have to be faked with const)

- no generics

- no exceptions

- no use of operators as function/method names

- no fine grain control over const/mutable data

- no metaprogramming

One of my favorite computer scientists, Donald Knuth, suggests avoiding C++ altogether, as it is too complex. I suggest that he has a proper CS background.

Really?

<quote> C++ has a lot of good features, but it has a lot of dirty corners. If you don’t mind those, and you stick to stuff that can be counted well-portable, it’s just fine. </quote>

Taken from http://drdobbs.com/blogs/architecture-and-design/228700500

Plus he even adapted his cweb tool to C++ http://www-cs-faculty.stanford.edu/~uno/cweb.html

Somehow I think he has a different opinion than what you are saying.

Continuing with the rest of your paragraph in your first link:

There are many constructions that are ambiguous, there's no way to parse them and decide what they mean, that you can't trust the compiler to do. For example, you use the "less-than" and "greater-than" signs not only to mean less-than and greater-than but also in templates. There are lots of little things like this, and many things in the implementation, that you can't be sure the compiler will do anything reasonable with.

And he goes on to suppose what another CS practitioner might say:

DDJ: You've mentioned Edsgar Dijkstra. What do you think of his work?

DK: His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.

JWZ, who Peter Norvig called the best programmer that he ever worked with, offered a scathing analysis of C++ and its contribution to the failure of Netscape. (Coders at Work http://www.codersatwork.com/.) In the same book, Ken Thompson offered a similarly negative view of the language and its genesis.

For some detailed issues, read all of http://yosefk.com/c++fqa/. Funny but not funny.

I say this as one who spent 10 years programming in C++. Those dirty corners that Knuth mentioned are different with every team practicing C++, resulting in a style guide that cordons off chunks of the language.

Dijkstra stopped using computers for work around 1972, and the last programming language he used was ALGOL, so his opinion about C++ most likely does not count.

About JWZ, I would not say that someone that throws chairs around rooms, and dedicated part of his life to flame C++, has a thrusty opinion about it.

Finally, Ken Thompson has stuck in C for so long, and even Go is just a better C, that I doubt he really understands the concepts behind the abstractions C++ offers.

In the end it goes back to people using C++ without proper background.

The world is complex and most languages that try to be the tool from low level systems programming up to normal business applications, end up being complex. Even if they start simple.

Any modern language that tries to replace C++, will end up being as complex.

PL/I, Ada, D, C#, Haskell, OCaml, Scala, Lisp are all examples of languages that have a kind of similar complexity level with C++, and also require people with proper CS background to handle them. Sometimes the complexity is the language itself, other times it is the abstractions it offers.

Judging from the skill set I see in cheap labour in IT, even BASIC is too complex for many people.

I am not on a crusade to defend C++, I also find that it has many warts and we need a better systems programming language, which is also able to offer the control and set of abstractions that C++ does.

Now will it be D, Rust, Clay or something else?

Until it happens, C++ will be the only answer for a class of problems.

C++ has heaps of interesting stuff in it if you're willing to learn the oddities inherited from C. C++ runtime is 100% imperative, but e.g. templates are completely purely functional.

Reply on news.ycombinator.com