[nly]

You seem to think I'm dismissing C. What I'm really trying to express is that I'd recommend people learn C++ and consider C an old-school 1980s, unsafe, rather laborious, subset of it.

> We do still have a need for a low-level language

C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'?

> There is also quite a bit of C code out there... not knowing C means being cut off from all of that.

I agree. Fortunately, you can't really effectively learn C++ without understanding its C legacy.

> The high-level features of C++ are polluted with low-level concerns that serve as nothing more than a distraction

Until you're working at a high level and need to dig deep and implement a gritty data structure or algorithm with a high-level interface. Sure, you can drop down from Java to C, for example, but then you're in the mud writing JNI bindings. Why do languages have to be constrained to 'high-level' and 'low-level' pigeon holes? Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?

Honestly, I don't want a religious war about it. I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible".

On another note, C++ is at least improving and rapidly becoming better tooled, with a growing sense of developer community. C has had a few sprinkles of improvement, but has otherwise reached the end of its natural evolution.

[orclev]

If you need C you should write C. If you don't need C, you should write in something nice, I.E. not C++. Why sacrifice ease of use 90% of the time in order to gain access to low level features 10% of the time? Any high level language worth anything has the ability to call C code via some mechanism (some better than others, Java probably has the worst mechanism out of any high level language). Use two languages that work really well at what they do, rather than one that sucks equally at both.

[nly]

That's just like, your opinion, man

I think C++ is the best procedural, 'high level', statically typed language out there. I also happen to think it's the best portable 'low level' language out there. What would your recommendation be to go alongside C?

[creatio]

I agree. I have touched Java, C#, Clean, very little of Haskell, VB.net, PHP (currently main one). I did some small scripts in python, and only read about scala, but haven't really touched it yet.

I recently (about 2 years ago) started writing, on and off, a new IDE for Clean in C++ with Qt. No complaints. I somehow like it better than C# with all its drag and drop capabilites (yes Qt has that also). However, somehow I like Qts way of doing it better...Don't know what I wanted to say with all this, I just prefer C++ and would choose it for applications. Unless demanded otherwise.

[betterunix]

"C++ can be 'low-level' if that's what you're going to label C. How can you dismiss C++ as not being low-level and then later say it's 'polluted by low-level concerns'?"

What I said was that C++ has no advantage over C as a low-level language. When you are writing low-level code you usually do not appreciate implicit function calls, extra data being allocated that you did not explicitly declare, name mangling, etc. Low-level C++ code is basically C with a slightly modified set of annoyances balanced by a small set of conveniences.

"Why can't there be room for a language that's good, but perhaps not elegant, slick or beautiful, across the spectrum?"

It is not about being slick and elegant, it is about being productive. The majority of applications are high-level, and the programmers who write those applications get more done when they use high-level languages.

Sure, sometimes an application needs to do a few low-level things. For some high-level languages that means using an FFI (e.g. JNI for Java). We could do better if we wanted; CMUCL and SBCL are Lisp implementations that do a fantastic job of separating high-level and low-level constructs, so that you would never know the low-level features existed if all you wrote was high-level code. With C++, you get something very different: high-level code is tangled up with low-level constructs, issues, and reasoning.

"I just think some of your assumptions are typical of people who have obvious had a bad experience with C++, having used it in a specific context, and therefore think "It didn't work for me, therefore it must be horrible"."

Actually, I switched from C++ to Lisp after having programmed in C++ for more than a decade. This is not a decision I have any serious regrets about. With Lisp I am writing high-level code more easily, and what I am seeing is (a) better performance, (b) the ability to do more ambitious things, and (c) less time spent debugging. Sure, I have bugs in my Lisp code, but those are exclusively high-level bugs -- bugs in logic, bugs that I can fix without having to spend hours tracing pointers. In Lisp, I can report errors anywhere and not have to worry that my program will abort; in C++, sometimes errors just have to go unreported.

It is not that I had one bad experience with C++. I TA'd a data structures course that was taught in C++, and it was a nightmare that left the students with a poor understanding of basic data structures. I have spent countless hours debugging C++ code -- code I wrote, code others wrote, code written by gurus, code that is supposed to solve high-level problems, etc. My group almost missed an important deadline because of the time we had to spend getting C++ code to work. I have worked with people who refuse to even use C++ exceptions because of the all the problems they cause.

Really, I do not mean to rave about Lisp. It is a great language, but there are plenty of other great languages. I liked programming in F#, though I am not an expert in the language. I have seen people switch from C++ to Haskell without ever regretting their decision (including a number of people who said they would prototype their code in Haskell, then rewrite it in C++ when they needed better performance; the rewrites never happened).

"On another note, C++ is at least improving"

I found C++11 to be a disappointment, and C++14 is looking to be more of the same. C++11 contains lots of fixes to problems that are particular to C++, and those fixes introduce as many problems as they solve.