Hacker News Reader

Comment by pmjordan | Hacker News Reader

I think C++'s popularity comes from the fact that it is essentially a better C. Which parts of it are better than C happen to be a matter of taste and for what you need it. I don't think anyone loves all of C++. But I think there isn't a viable competitor in the "C, but better" space at the moment. Go is probably too high level to be a complete replacement. D is... a weird case. I don't think it stands much of a chance in the market because it's not sufficiently better than C++. Overcoming C++'s momentum is extremely difficult at this point.

EDIT: downvoters: if you think I'm trolling, please note that I've written more code in C++ than any other language. I would love a "better C" that's universally better than C++. If you disagree with my points, please elaborate.

View on HN

> But I think there isn't a viable competitor in the "C, but better" space at the moment.

In the Microsoft ecosystem, C# is this. No, C# isn't OS-independent or hardware-independent or HTTP-server independent. It's not meant to be. C# isn't meant to be an abstractly beautiful language like Lisp or highly performant and portable like raw C. And it's not intended to be part of the LAMP free-software stack; it's intended for a business context that can spend a bit of money to make money. (The C# compiler is actually free, though the IDE isn't and of course the underlying Microsoft OS isn't.)

It's C and most of C++ without the foot-shootiness or Java verbosity. For what it is meant to be and for the problem domains that it serves, C# really does make for great productivity. My company and I have used it as our primary language for several years and I like it a lot. Most of the productivity comes from tight integration to external ecosystem elements that make for a useful application, notably MS SQL databases and ASP.NET web servers, all wrapped within a solid IDE. More productivity comes from getting to ignore things like memory allocation and header files which the language just handles for you. Perfect for simply getting things done in a business context when things like price and portability are not a concern. (When they ARE a concern, then by all means use the LAMP stack and C# is not for you.)

I think most of what can realistically move to high level languages already has (minus legacy code). Java and VB was the first mainstream wave, C# the second. They're sometimes still lumped in with "systems" programming, but I don't think that's a useful description. As such, when I talk about C++, you can assume I'm excluding situations where a managed, VM'd language would work fine.

Calling C# or Java a "better C" is therefore not terribly useful. C is not good at the things C# is good at and vice versa. I use about 6 or 7 different languages on a regular basis, and often the only choice is between C and C++.

I'm not sure where you're going with the second paragraph. C and C++ were never popular for general web app development.

"Perfect for simply getting things done in a business context when things like price and portability are not a concern. (When they ARE a concern, then by all means use the LAMP stack and C# is not for you.)"

You've been brainwashed by Microsoft. No one using LAMP cares about price (that much) or portability ('L' is for Linux). Freedom from vendor lock-in (and in this case, a predatory, vengeful vendor) is the biggest practical advantage. Stability and the thing actually fucking working is another (I never enjoyed babysitting Windows servers; do you?). It's also easier to build robust applications with LAMP.

Enjoy paying your Microsoft tithe, peasant.

Curious; what makes ObjC not a viable competitor IYHO?

D is doomed by the Phobos/Tango schism, no-one would risk their business on it.

Curious; what makes ObjC not a viable competitor?

The Objective-C additions just aren't very low-level. They're basically an object runtime library with some syntactic sugar. This is fine for situations where you want something a bit more high level and dynamic[1], but gives you no advantage over C in something like device drivers or programming embedded devices, because you just aren't going to use those features. Minimalistic (optional!) vtable dynamic dispatch is great for these uses, though, and generic programming can be really nice (despite C++'s version in the shape of templates) even for low-level applications. RAII also is really nice.

D is doomed by the Phobos/Tango schism, no-one would risk their business on it.

If D was that much better, I think a sufficient open-source ecosystem would spring up around at least one of the two libraries that you could realistically use it. As it is, I doubt it would be popular even without the schism.

[1] Though in my opinion, most iOS apps would be easier to write in a managed language, especially if you could call out to C/C++. The Obj-C focus is understandable from Apple's point of view though.

"Though in my opinion, most iOS apps would be easier to write in a managed language"

Maybe, but just as you can not easily dismiss C++ because so many people have written so many successful programs in it, it is difficult to dismiss all of the great software from Apple, and arguably the largest library of software for mobile devices in the App Store, written in Objective C.

You point out the resource constraints that make C++ superior to Objective C and other languages for drivers and embedded systems. Similarly, I suspect Objective C gives Apple the right trade offs for writing sophisticated software for mobile devices that is responsive, uses memory effectively, and does not kill battery life.

FWIW, I agree that it's not a black & white issue, and I don't have an immediate suggestion for a replacement language that would be better than Objective-C in every aspect.

I thought that one of them was going away with D2?

> But I think there isn't a viable competitor in the "C, but better" space at the moment.

C99 is such a contender imho.

C99 is such a contender imho.

C99 is a pretty tiny (but welcome) incremental improvement on C. It's also almost entirely orthogonal to C++'s additions. Calling C99 a C++ replacement is pushing it, so you'll need to elaborate on why you think so. I'd be curious about an instance of something you can do better (let alone fundamentally better) in C99 than C++. I can think of plenty of examples of the opposite.

C++ sometimes makes me want to tear my hair out, sure[1], but when using pure C(99), I find myself thinking, "this code would be so much more compact in C++."

[1] This is usually because either I or someone else tried to be too clever. Otherwise it's because of something C++ does badly that neither C89 nor C99 do at all.

> Calling C99 a C++ replacement is pushing it

I didn't call it a C++ replacement. Just a C89 replacement. "A better C" :)

> I'd be curious about an instance of something you can do better (let alone fundamentally better) in C99 than C++.

It depends. If you need C++'s syntactic sugar for OOP-style code then yes - C++ is better for that. But if you don't do OO-heavy stuff you can use plain C and get away with less complexity (and more control over the instruction cache, etc).

I'm in the lucky position of not needing OO so I get away with using C. And C99 makes my life, compared to the old C89 standard (and the C++ C subset), easier. I can declare variables in the middle of a function (or even within the if statement!). I can initialize structs by its member's names thanks to designated initializers. And the implicit "upcast" from void* to whatever is a blessing (though possible in C89 it isn't available in C++). Oh, and I almost forgot variable length arrays.

> but when using pure C(99), I find myself thinking, "this code would be so much more compact in C++."

Well, this can go the other way round, too. Just take the right tool for the job.

Okay, all of these points are fair enough. I guess I didn't make it clear enough, but:

There's no language currently out there that covers as much ground as C++ and is anywhere near as good at it. C99 falls into a similar bucket as Go or Objective-C in covering a subset of cases where C++ is useful.

The point of the detractors, though, is that if only a subset of the language is good for any particular task, why not skip the subset operation and just choose a language better for the task?

I echo that sentiment. I'm using C++ in my current project (first time in many, many moons), and it dies what we want reasonably well, but it is bigger than any language needs to be.

Because there's less cognitive overhead in learning 5 variations on one language to do 5 tasks than there is in learning 5 languages to do 5 tasks. You don't have to relearn what semicolons, parentheses, braces, colons and so on mean. You just have to learn how inheritance works. Or the STL. Or whatever.

> There's no language currently out there that covers as much ground as C++ and is anywhere near as good at it.

Have you tried OCaml? It's has it's problems, but it's nowhere near as bad as C++.

Perhaps as a counterexample, when I'm write some linear algebra code that I expect to perform reasonably well, I greatly prefer using eigen to other BLAS implementations (well, except the MKL, but that's a different matter entirely.)

Reply on news.ycombinator.com