Is C++ a 'Really Terrible Language'? (gamesindustry.biz)

Long-time Slashdot reader slack_justyb writes, "Jonathan Blow, an independent video game developer, indicated to gamesindustry.biz that while working on a recent project he stopped and considered how miserable programming can be. After some reflection Blow came to the realization as to why. [C++ is a] 'really terrible, terrible language.'"

The main flaw with C++, in Blow's opinion, is that it's a fiendishly complex and layered ecosystem that has becoming increasingly convoluted in its effort to solve different problems; the more layers, the higher the stack, the more wobbly it becomes, and the harder it is to understand.
"Blow is the developer of two games so far -- Braid and The Witness -- and developed a new programming language known as Jai in hopes to help C++ game developers become more productive."

With Jai, Blow hopes to achieve three things: improve the quality of life for the programmer because "we shouldn't be miserable like many of us are"; simplify the systems; and increase expressive power by allowing programmers to build a large amount of functionality with a small amount of code.

Long-time Slashdot reader xx_chris calls C++ "the triumph of syntax over clarity," while in the interview Blow calls C++ 'a weird mess.' But the original submission ends with these questions. "Is Blow correct? Has C++ become a horrific mess that we should ultimately relegate to the bins of COBOL and Pascal? Are there redeeming qualities of C++ that justify the tangle it has become?

"And is Jai a solution or just yet another programming language?"

Comments

Yes

[Anonymous Coward]

Yeap.

Re:Yes

[Joce640k]

Nope.

People who don't understand C++ are doomed to recreate it, badly.

Re:Yes

[Anonymous Coward]

I use lots of C++. I also ignore major portions of it. I do not need all of it. There is nothing saying you have to use every bit of it. It is good to know all the bits though and understand how the tool can help you get things done. Take for example Visual Basic 6. Not exactly a 'bad' language. But it sure let lots of bad things to be created. That is because it was an easy lang to pick up and make a mess of. Being good at what you do takes time. There are no shortcuts. Blaming C++ is kind of a fad. Because like all languages terrible things can be done in it. It will not stop you from doing that. It expresses what you want. If you are not good at what you do you will express bad things. I have seen monsters made in pretty much every language at this point. None of them are 'good' at stopping you from making crap code.

Re:Yes

[Narcocide]

Doesn't happen much, but this time I'm going to have to agree with Anonymous Coward. All that will be accomplished by making programming languages easier is fostering the proliferation of even less qualified jackasses flooding the market with dangerously insecure and buggy code.

Re:Yes

[Joce640k]

Yes. Even Bjarne said (something like): "Inside C++ is a smaller, cleaner language trying to get out".

The trick is to learn what to use and what not to use.

The main problems C++ has are:
a) It's hard to learn C++ by hacking away at it. Some things are counter-intuitive, a good C++ mentor can save you years.
b) It's not a platform. Casual programmers don't want a "language", they want a platform.

The bottom line is this though: C++ allows you to precisely express anything you want to do. You never hit a brick wall like you do in other languages.

Also: Garbage collection is a red herring. Nobody manages RAM in C++ because C++ understands RAII like no other language. All the garbage collected languages handle RAM OK but RAM is only one type of resource. You end up explicitly closing files, etc., when you finish with them. In practice, GC actually creates more work for you compared to C++.

Re:Yes

[Joce640k]

The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained. Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.

- Bjarne S.

Re:Yes

[blackpaw]

Yes and no, I agree you can do clean, lean good code in C++, but its when you try to avoid reinventing the wheel by pulling in 3rd party libraries that it all goes wrong. Or even the std ones for that matter - the string template library is a classic example, a monster of templates and polymorphism gone insane. If I have to pull out the docs to remember how to convert a string to lowercase, there's a problem.

Re:Yes

[MichaelSmith]

There is nothing saying you have to use every bit of it.

Other than the guy you inherited the codebase from.

Re: Yes

[Joce640k]

Each job requires a slightly different subset, yes.

There's not much you could take out of C++ without harming it in some way, every feature is needed in some circumstance or other.

The only completely useless feature I con think of is C++ arrays - new[] and delete[] don't do anything that can't be done much better with std::vector.

(nb. Arrays were added before templates so that's why they're there)

There's also a bunch of small tweaks that could make it better, eg. require {} on all code blocks.

Re: Yes

[Anonymous Coward]

I'm convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does.

- Bjarne S.

Re:Yes

[K. S. Kyosuke]

I think that's a very flawed argument. You have no control group in the form of another universe where C++ didn't gain the same popularity and the same programs were developed in an alternative language. Only then could you assess whether C++ helped you write those programs or whether it hindered you. Just because network effects, for better or worse, made most people use it in our world says little of its technical merits.

Re:Yes

[Narcocide]

Try actually signing up for a Lisp class and you'll find out exactly why.

Re: Yes

[mikael]

I would believe that. There's about two dozen ways to iterate through an STL vector class; by integer index, by iterator begin/end, by auto iterator by value, by auto iterator by reference, these can be done backwards from end to start as well. Another combination is whether to pre-increment or post-increment. But only one method will actually be the fastest on any platform. Then you could use pthreads to parallelize things or maybe Intel TBB blocks. Depending on whether you are working with vector data, then the Intel/AMD AVX/AVX-256 and AVX-512 are another option.

In many companies, they would split this into multiple tasks. Get something simple working. Get someone else to investigate how to optimize the single core version. Now get someone else to investigate multi-threading. Then get the AVX optimization expert to have a go.

There are Youtube videos where the developers have managed to write a C++ compiler to generate 8-bit 6502 code. Just by using the const keyboard they could make a kilobyte of data and code just disappear.

Re: Yes

[Anonymous Brave Guy]

new[] and delete[] don't do anything that can't be done much better with std::vector.

Well, they can be used to implement std::vector.

Re:Yes

[careysub]

I hope you get modded way up! This is the fallacy of the "but only use a subset and you are good".

Real world programmers must maintain and modify code bases that have been written by people that no one currently at the company even knows.

Re:Yes

[dfghjk]

The discussion is moot when it involves inherited codebases. You are compelled to use the tools already selected whether you like them or not.

Re:Yes

[SoftwareArtist]

Inside C++ is a small(er), clean(er) language trying to get out, but it's still neither a small nor a clean language. It's still a verbose, inconsistent, badly designed language.

Why do you need to separately declare and then define every piece of your API? Because that's how C worked, and C did it that way because of the limitations of compilers in 1977. It's totally unnecessary in a modern language, and it makes your code way less clean. But that's how C++ works.

Why are templates designed in a way that makes you put the entire implementation in the header file? That was totally unnecessary, and it leads to clunky code. But that's how C++ works.

How come if a parent class doesn't mark its destructor as virtual, all subclasses will (silently) fail to get cleaned up correctly? This is just bad design. It's probably caused countless bugs over the years.

The language is full of inconsistencies because no one ever bothered to fix them. Why is "this" a pointer instead of a reference? Why does exception.what() return a char* instead of a string&? There are tons of minor points like this that could easily have been better if someone had bothered to think about consistency. But no one did.

You can avoid the worst parts of C++, but what remains is still a poor substitute for a well designed language.

Re:Yes

[S.Gleissner]

Why do you need to separately declare and then define every piece of your API? Because that's how C worked, and C did it that way because of the limitations of compilers in 1977. It's totally unnecessary in a modern language, and it makes your code way less clean. But that's how C++ works.

You don't have to. You can define all your code inside of the class, like in Java. It's up to the compiler/linker to store that mess somewhere. But for non-template code, it's more efficient (speed and memory) to have this separated, for both compiling and linking.

Why are templates designed in a way that makes you put the entire implementation in the header file? That was totally unnecessary, and it leads to clunky code. But that's how C++ works.

Because the compiling of the template is totally depending of the template arguments. Last time I've looked into Java, there were no templates (or even variadic templates), so this is really not comparable.

How come if a parent class doesn't mark its destructor as virtual, all subclasses will (silently) fail to get cleaned up correctly? This is just bad design. It's probably caused countless bugs over the years.

Only if the subclasses have virtual functions, then you should also make the destructor virtual. There are good reasons to have non-virtual destructors in parent classes. Why should I pay for a feature, if I don't need it? Here static code analysis helps.

The language is full of inconsistencies because no one ever bothered to fix them. Why is "this" a pointer instead of a reference?

Is this really an inconsitency? For me, pointers are no problem, they are an additional grade of freedom for expressing what I want. Yes, references are internally only pointers with the same speed and they normally don't have the value 0 (as long as you did not mess them up), but last is also true for 'this'. So it really doesn't matter.

Why does exception.what() return a char* instead of a string&?

Good question, but nearly irrelevant in well designed programs, that try to avoid exceptions during normal program flow. However, if you want to concatenate constant strings at compile time to get better error messages, there are tricks with variadic templates. With gcc, this even works with __PRETTY_FUNCTION__.

There are tons of minor points like this that could easily have been better if someone had bothered to think about consistency. But no one did. You can avoid the worst parts of C++, but what remains is still a poor substitute for a well designed language.

Perhaps. This language is for professionals. It is huge and there are pitfalls. But it gives you the neccessary freedom to express *exactly* what you want. C had been designed as a shortcut for Assembler and this is still true for C++; there is no virtual machine in between. If you write business applications, well, then use something else, but I do embedded development in the automotive sector and here C++ is exactly what I want.

Re:Yes

[Anonymous Brave Guy]

I take your point, but I don't entirely agree with it. I think whether performance or maintainability matters more depends a lot on context. Both are valuable attributes, but both can reach a level that is good enough to get the job done, and improving them beyond that point offers a much lower return. Where that point is depends a great deal on both what you're doing now and what you might want to do later.

In any case, the days when writing in C or C++ was an effective guarantee of very good performance are behind us. With modern hardware designs, the only way to guarantee making the most of available CPU and other hardware resources is to drop to assembly level or the equivalent. Otherwise it's still a question of how good your compiler or VM is, and while C or C++ being "closer to the hardware" can offer some advantages there, their programming models also prevent some optimisations that might be valid because, for example they aren't safe due to aliasing possibilities.

Re:Yes

[thegarbz]

Why are templates designed in a way that makes you put the entire implementation in the header file?

Oh is that a thing? I am nothing more than a casual hacker at the language, more of a C person. The other day I saw my first template and was confused that the header seemed to do the heavy lifting.

I'm always amazed at the things I learn on Slashdot.

Re: Yes

[Miamicanes]

Bad example. An architect who designs mostly single-family homes, strip malls, and chain restaurants isn't going to design megastructures like the Burj Khalifa, EVEN IF the buildings they design are visually-spectacular works of art that are perfectly-tailored to their intended uses.

Ditto, for a thoroughly-competent & thorough (but mostly un-creative) structural engineer... you might sleep better at night knowing that he or she designed the bridge you could be driving on when an earthquake strikes, but a skyscraper designed by him or her would be pretty bland.

The buildings that combine both size and design come from the elite few who've mostly-mastered one realm, while becoming acceptably-competent in the other. Artistic vision in the architectural realm means little if it can't translate into something that can actually BE constructed, but buildings designed by ARTISANS (vs artists) end up being... well... mere steel-framed glass boxes, like most "modernist" skyscrapers. Modernists were artisans, not artists. They built what was technically-possible, and sprinkled on some frosting as an afterthought to make them look less bland (or proclaimed their very bland-ness as an artistic virtue).

The era between beaux-arts & postmodernism was when architects slowly began to broaden their knowledge into areas formerly of interest only to structural engineers.

Brutalism was their first baby steps, where they leveraged their knowledge about the stone-construction techniques of antiquity and extended it with knowledge about reinforced concrete to design structures that were big, but still tried to have artistic merit & express good design.

Today's postmodern skyscrapers are simply the next logical step... having reconciled stone-masonry of antiquities with reinforced-concrete engineering, they kept pushing the limits until they learned how to build skyscrapers with exteriors that were (or at least resembled) more aesthetically-pleasing materials... stone, brick, textured concrete, glass, and combinations of all four (though generally NOT wood... at least, not as an exterior or structural element).

"Brutalism" was a rebellion by architect-artists against uninspired blah modernism designed by committees of artisans. It didn't die... it just evolved into postmodernism as architects became increasingly competent at applying the principles of modern structural engineering to the aesthetics of creative artistry & saved us from BOTH bland, uninspired glass boxes AND hulking masses of gray concrete. Today, thanks to the increased fusion of those two domains, we get to have our cake & eat it too... inspired artistic vision that pushes the limits of building construction and expands the range of possibilities.

TL/DR: narrowly-competent artisans have their place, but multitalented renaissance men/women are what really move us forward.

C++ is a terribly documented language.

[Futurepower(R)]

C++ is a terribly documented language. Powell's Bookstore in Portland, Oregon, one of the biggest bookstores in the world, had 16 books about C++. All of them were about the many tiny details of C++, with no attempts to show how the language should be used.

Powell's Books | The World's Largest Independent Bookstore

Use a subset

[Anonymous Coward]

And choose your libraries wisely.

Know what things to avoid.

[Anonymous Coward]

Part of the challenge of using a language is not just knowing all of the things you *can* do. It is also knowing which things are best to avoid, and what the pitfalls are.

Re:Know what things to avoid.

[AmiMoJo]

Depends how you define "performant"... Which isn't a real word but the point is that if you want performance on say an MCU, C++ is mostly useless and you will end up writing code that is 90% C with a bit of OO for organisation.

Even on powerful systems the best performance is only available if you avoid using C++ features that cause memory allocation and the like, at which point you are mostly using it to make the code itself nicer.

On a related note I think this is one of the major reasons that driver code is often so terrible.

No it's not.

[Anonymous Coward]

No C++ is not a terrible language.
It's still IMHO the best general purpose language there is, but it has grown a devilishly high threshold to master.

With "general purpose" I mean a language you can use in both user-mode and kernel-mode, that you can use to express and implement anything in.

It's like a toolchest with so many tools it'd baffle a newcomer, and probably not even half of them would be user by a master craftsman in a single project, but together they create the best toolchest there is - is looking only at a single language.

Perhaps that last point is what most miss - there is no silver bullet.

Re:No it's not.

[OneHundredAndTen]

It's a worthy conceptual child of PL/1.

Doctor, it hurts when I go like this

[Anonymous Coward]

If one uses every single feature of C++, then it's probably a really terrible language.

If one only uses features that make C++ better than C, then it's usually good enough.

Re:Doctor, it hurts when I go like this

[geoskd]

If one uses every single feature of C++, then it's probably a really terrible language.
If one only uses features that make C++ better than C, then it's usually good enough.

C is the original performant language, but it turned out to be only marginally easier to maintain than assembler.

C++ was originally intended to make the code easier to maintain, but like all efforts in that direction, the cost was in performance

Then in the early 2000s, it was discovered that there were some really performant things you could do with C++ that didn't hurt the maintainability, and now it is possible to write C++ that is both maintainable and highly performant. The problem is that the cost of this bargain is that there is a very high complexity to the task. Mediocre programmers can still manage to write performant code that is un-maintainable, or slow code that is easily maintainable, but an expert can achieve both.

C is no longer the performance king. A highly skilled C++ programmer can write c++ code that will outperform even the best C code. The cost of that performance is template meta-programming. It's a higher level of abstraction; its bitchy hard to understand; it's 100% necessary for performance; deal with it.

Modern programmers should be required to demonstrate proficiency with template meta programming as a prerequisite to being allowed to practice, much the way a course in lisp is included in virtually every accredited computer science degree.

You are holding it wrong

[Nkwe]

C++ is not necessarily a horrible language, but it does allow you to write horrible code. You can also write easy to read well organized code that is "good" - it's entirely up to the developer. With great power comes great responsibility, yadda yadda.

You can write really good or really bad code in pretty much any language. Generally if your code ends up unreadable, you are doing it wrong.

That being said, if the semantics of a language tend to encourage people to write horrible code, does it make it a bad language? Good question. Discuss.

Re:You are holding it wrong

[david_bonn]

That being said, if the semantics of a language tend to encourage people to write horrible code, does it make it a bad language? Good question. Discuss.

My first observation about C++ is that the best examples of clean, well-written code in C++ tend to use a very constrained subset of the language.

My next observation is that over the years many of the features added to C++ seem to be very obscure and seem to address odd corner cases. I suspect this is because of some deep design flaw in the language.

C++ tends to reward a programmer who can design clean, graceful interfaces that can successfully evolve over their lifetimes. And C++ mercilessly punishes programmers who cannot do that. Unfortunately, the vast majority of programmers cannot design clean, graceful interfaces. And very few programmers can do so all the time.

So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.

Re:You are holding it wrong

[geoskd]

So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.

Think about it a little differently: There are a few primary goals when writing code. The first is speed of coding: how fast can the developers get the work done. The second is maintainability: How easy will it be to get new developers up to speed on the project, and how easy will it be for them to add new features. The Third is code performance.

Some languages address the first item very well. Python is a good example of a language that allows you to get something working very quickly. It can be maintainable or not depending largely on the quality of the code that is written and the presence (or lack) of comments. Python simply cannot be performant. It is an interpreted language, but even compiled, it cannot achieve high performance because it lacks the language constructs necessary to permit high performance computing.

Some languages address the second very well. Java was designed to be a language that follows a rigid pattern of development that should be very similar across projects. In theory this should allow a developer to come up to speed more quickly because there is only one way to do each thing that needs to be done. In practice, Java developers can write horrrendous code too, and for the similar reasons to Python, Java simply cannot be performant.

For the third, there are very limited options for raw performance. They really are: Assembler, C++ and C, in descending order of absolute performance (C++ might even edge out assembler now thanks to TMP. In theory you could implement the same thing in assembler, but good luck). Developers can write maintainable code in any of the three, or they can write junk. It really depends on the developer.

At the end of the day, the first two priorities can be had in any language depending on the skill of the developer, but the third priority can only be had in those three languages. It is due in no small part to those capabilities that C++ is as complicated as it is. It can do things that *no other language can do*.

In the end, if there is even the slightest possibility that performance will be a project priority, then you are limited to C, C++ or Assembler.

Re: You are holding it wrong

[geoskd]

When coding with assembly, programmers would use macros in the same way templates were used. You would define your macro with parameters defining the local name of each register storing that variable. Then if you wanted to reorder register usage, you just change the order of the parameters in the macro call.

I'm afraid you have not only missed the entire point of templates, but also their most powerful capabilities as well

Templates are for implementing the same function multiple times with variations between them, but without having to rewrite the whole function in every variation you want to implement. For example: (I apologize about the formatting)

template<tbool T_bRounded>
void foo()
{
//Do some stuff to find x
if( T_bRounded)
{
return( round(x));
}
else
{
return(x);
}
}

This simple function implements a call that either returns x, or rounds it first, and then returns it. The magic of the implementation is that the conditional on T_bRounded does not result in an actual jump instruction. Instead, the function is instantiated twice, once with the return in the if clause, and once with the return in the else clause. The correct function is called based on the template parameter that is used. For this simple example, it is not terribly useful, but imagine that foo has an inner loop where T_bRounded gates a particular behavior that is executed millions or billions of times. Not having that extra conditional jump in the assembled code will make a huge difference to the resulting compute time. That is a simple example of the real power of TMP. Imagine if you have a dozen such booleans that you want to gate out various behaviors from an inner loop. You could easily double or triple the speed of the inner loop. The only way to write competing code in C would be to write 4096 versions of the function with all possible combinations of the twelve flags, and call the correct one based on the flags using a jump table. What are the odds that you could write all 4096 without having a significant number of mistakes? With TMP, you write it once and the compiler spreads it out for you.

Create C+++ Then - With A New Syntax

[dryriver]

Keep the compiler, keep all the powerful capabilities of C++, and add an alternative syntax - a friendlier one - that people who struggle with C++ can more easily learn and more easily manage. Back in the days of Flash, Actionscript first had one syntax, and then got a 2nd alternative syntax. You could use either one. The same can be done with C++. Create a new syntax for use in the 2020s and beyond. Don't destroy everything that makes C++ great in the process. There is your "new" language - C+++.

Re:Create C+++ Then - With A New Syntax

[Nkwe]

Keep the compiler, keep all the powerful capabilities of C++, and add an alternative syntax - a friendlier one [...] There is your "new" language - C+++.

Go one step farther and make it four pluses, arrange them in two rows of two and you have C#.

C++ is great

[Actually, I do RTFA]

You can write really great code, short and powerful. You can also write really bad code. In this way it's similar to other languages. However, I've found it far easier to write multiperson, maintainable code in C++ than in JavaScript.

It does suffer some from things like iterators and safe pointers being added... 1/2 way through it's lifecycle. And therefore, they are less clear than they could be.

Re:C++ is great

[mykepredko]

Saying it's better than Javascript isn't a ringing endorsement.

Re:C++ is great

[djinn6]

However, I've found it far easier to write multiperson, maintainable code in C++ than in JavaScript.

Having worked with well-written projects in both languages (as well as several others), I must disagree. Javascript can be written with maintainability in mind and it doesn't take a genius to do so, only discipline. But C++ is difficult to work with even in the hands of an experienced developer. You end up spending half of your time wrestling with the language to get it to do what you want and the other half digging through core dumps. It's also extremely unforgiving of any mistake. If you're lucky, the entire program crashes. If you're not, it'll go on happily corrupting all of your data. And the fact that it's so difficult to write unit tests doesn't help either.

You can argue that an expert should not be making those mistakes, but in reality, no one is perfect 100% of the time. And even if you were, is it really worth spending that much effort on something a better language or runtime would just handle for you?

Re:C++ is great

[djinn6]

My previous post mainly focused on why it's hard to maintain in general. To answer your question, I think by far the biggest difference is readability, and JS being a higher-level language makes it much easier to understand what the code author intend it to do. It hides much of the details with weak typing and automatic memory management, so what a reader sees is just the logical flow.

Yes, the compiler can enforce certain rules, but it's not foolproof and there are lots of ways to misuse a class or function that the compiler cannot check. At some point, the person using the interface needs to understand how it works. While clear documentation is far more important than the code itself for that purpose, diving into the implementation to figure out some detail still happens quite often, as is looking at the unit tests.

The more recent changes to C++ significantly improved readability, but still not to the degree higher-level languages can accomplish. I still run into macro and template magic that takes far longer than it should for me to parse.

Was OK for the '80's, But Its Time Has Past

[Bruce Perens]

C++ is a 1980's language (actually, Bjorn started work in 1979). It's lasted long enough that we don't have to shed any tears for its demise.

We have many better options today. Personally, I am writing in Crystal, and you can see my explorations here:

• Introduction.
• Why Dynamic Linking Doesn't Make Sense for Modern Languages.
• Tiny Crystal.

ALOTD (another language of the day)

[jmccue]

I am no fan of c++, and I agree it is terrible. But, creating yet a other language sounds a bit over the top.

I am convinced this is happening for one reason, companies do not want to train anyone! If they took the the time to properly train people the industry would not be in this state, now we get new methodologies and languages every other day.

When I started out, senior people spent a lot of time with me showing how I can improve my skills and how the business works. These days you are expected to muddle along hoping to learn your job. No wonder we are having large breaches and crappy software

Re:Obcious

[david.emery]

Disagree. It's more convoluted than C, but adapts C's very error-prone syntax. It's more complex than Basic, FORTRAN or COBOL. It doesn't have the simplicity of Pascal nor the consistency of Java or Ada.

It's definitely a 'science experiment that escaped from the lab.'

Never learned C++

[innocent_white_lamb]

I've been programming for over 40 years (shudder..) and have always used C. Never seen a need for C++ for the sort of things that I do.

Perhaps it's because I don't do games and fancy graphics. I do things like counting pulses from water meters and getting coordinates from survey instruments.

You could get some really fancy graphics out of Amigas using C, though. :)

C++ is an engineering language

[stikves]

It is one of the things that is easy to learn, but takes many years to master.

The proper way to do things take a lot of discipline, and looking at the culmination of effort bringing really stable and predictable systems is satisfying. It is no longer as "visible" as other languages, but many of the software people use daily is still mostly C++ (and C of course). For Linux there is still heavy C usage (in the Kernel, X11/Wayland, and Gnome). However KDE desktop, LibreOffice, VLC, Firefox and many other projects are done in C++. Similarly for Windows low level interfaces are already in C++, and MacOS kernel and UI libraries also use C++, and Objective C++ (but not exclusively).

Yes, they are not "sexy" software items, but they work, and I have seen much less exceptions, crashes, and failures in proven C++ code, compared to many Java, Python, or JavaScript code.

A few new low level programming languages are trying to change the situation, but the progress is slow. It could be said that D was the initial one, later Go, and Rust came along. But still most non-experimental low level and mission critical software is still developed in C or C++.

So, no C++ is not a terrible language. It gets results, and many organizations still prefer to keep using it. Unlike older generation languages like COBOL (abandoned by banks), FORTRAN (abandoned for R/Python in scientific research), or Pascal (abandoned by Apple for ObjC++), the C++ community is still thriving.

It wasn't always shit

[Tsolias]

Before c++11, c++ had great features that helped you write cleaner code.
The last time I bothered in a bureaucratic way with c++ was in 2013 when I was in a committee to send some features in for suggestion.
The meeting had a lot of people yelling at a guy who was part of isocpp iirc half a decade ago, and he flew from usa for that purpose.
I left in the middle of this shit.
Long story short and I am adding here not only my opinion but the opinion of every colleague who wrote c++ in research labs in different hierarchy levels inside an os, C devs do need C++ to help them write code easier, without hassles and give them more tools when they need them.
C++ the last 10 years has been adopting the web dev language cycle.
You have to have the bleeding edge of features to stay relevant...as frameworks languages and apis die and born every day.
C++ has no enemies, yet it's getting tackled by its own people.
Instead of having powerful lean language, just like C, you have a clusterfuck of a language.
I stopped using the bewest and coolest features because most of them are useless and don't worth the extra effort to include them in your programming style and most importantly there are out there a shitload of colleagues who don't know or care about the latest and greatest feature.... Because they are s/w engineers, not programming hipsters.
I don't think c++ will ever recover. It will grow and grow in terms of features and also those features will become more and more irrelevant as less and less people will adopt them.
Tbh C with classes had a negative meaning 15 years ago. Now it seems like the sane way of writing good and intuitive c++ code.
Maybe it's just me.

Not my problem!

[Anonymous Coward]

C++ is one reason why I gave up programming and became a prostitute.

Re:Not my problem!

[Purity Of Essence]

C++ is one reason why I gave up programming and became a prostitute.

So PHP.

Person hates X, invents Y

[93 Escort Wagon]

These sorts of stories come up fairly regularly here on Slashdot. And, each time they do, it reminds me of the classic XKCD:

https://xkcd.com/927/

This doesn’t just apply to no-name indie developers... the good folks at Google are some of the worst offenders in this regard.

Blow is in good company

[Man On Pink Corner]

Even Stroustrup himself has been having second thoughts about building a time machine to go back and kill his own grandmother.

https://www.theregister.co.uk/...

I dunno, are swords really terrible weapons?

[engineerErrant]

Of course not. If it's 10,000 BC and your opponent is wielding an antelope's femur, having a sword is an overwhelming advantage! But in modern times, that answer changes. Now, a person clearly *can* be very effective with a sword, with a lot of training. But they could be much more effective with a .38, with much less training.

C++ is kind of like the sword of programming. It occupies an important place in history that should be remembered, and in the right hands, it's still fearsome. But gimme a break - in modern times, there are just better options, in every arena of computing. Other languages offer faster learning curves, less ability to blow your foot off because you didn't know some obscure intricacy of the language, and are simpler in pretty much every conceivable way.

C++ is a relic we should regard with a certain reverence, while not taking it seriously for the future.

Rust is that beautiful language within C++

[Anonymous Coward]

Bjarne is right: there is a smaller, beautiful language within C++: it is called Rust. Mozilla has taken the best parts of C++ like its fast performance and its flexible abstractions and created the ultra-safe, ultra-productive and ultra-powerful modern programming language called Rust. While C++ will probably never go away, more and more C++ programmers are opting to use Rust instead because it is so much like C++, yet so much better at the same time.

Re:Rust is that beautiful language within C++

[Carewolf]

The fact that the Rust developers knew C++ is why they while doom to recreate it, are not recreating it too terrible. It is basically a codification of C++2014 best practices, with syntax inverted so best practices is the shortest form, and bad practices look complex, while in modern C++ it looks the opposite. The fact you don't know C++ is why you don't like Rust syntax, and probably will not be able to understand the semantics either.

This is not your grandfather's C++

[mrsam]

Modern C++ looks nothing like C++ of the years past. C++ is a comparatively old language, it's been around for over 30 (!) years.

And for the longest time C++ was gathering dist, stagnating, and remaining basically unchanged. But an effort begun to update the language, and since 2011 in my estimation C++ is now at least three times as big, and as complex as it was before.

Folks who've been around the block for a while started getting someone shocked coming across C++ code that looked nothing like the C++ they knew. And people who attempt to start learning C++ from scratch were confronted with the entire, 100% complexity, of modern C++ right off the bat.

And that's, IMO, is where the current bad rap for C++ is coming from. It is a hard, complicated, language to learn. But it's been my experience that once I spent th effort to learn the nuts and the bolts of modern C++, I found it to be a very powerful, rich, capable language. I don't think I would've been able to write LibCXXW in 2003 C++. It would've taken me five or six times longer than it did. Modern C++ attempts, in made ways, to bring many of the benefits of other, VM-based languages like Java and Perl, and bolt them on top of a compiled framework.

Some time ago, on stackoverflow, I read a question from someone wondering why their C++ compiler was running out of memory compiling their code. I looked at it. The shown code attempted to implement Sieve Of Eratosthenes in the compiler itself. That is, the code was not trying to implement it itself, but make the C++ compiler do it, via templates, with the actual code resulting in a static array of prime numbers. And the question was why the poor compiler was running out of RAM...

Try that, with Java.

Yes and no

[russotto]

Yes it's terrible, no Jai or Rust or D or any other "language of the week" isn't going to replace it. They all fail on something. D has garbage collection. Rust comes with politics and really annoying fans. C++ doesn't even have fans. Plus C++ is well-entrenched; it'll be harder to dislodge than Fortran

And yes, there is a smaller and more elegant language inside C++ screaming to get out. It's called "C".

Re:Yes and no

[Joce640k]

And yes, there is a smaller and more elegant language inside C++ screaming to get out. It's called "C".

Especially C string handling, that's really elegant.

C arrays, too. Data structures that don't know how many elements they contain are awesome! Give me more of those....

Data abstraction? A piece of elegant cake in C. Take a look at the OpenSL ES library for an example of an easy to use library written in C.

Stuck with C++

[Tronster]

Almost two decades ago a I had a Thinkgeek C++ round bumper sticker on my car because I thought the language was the bees' knees. Today I'm finding myself holding my tongue in watching videos from C++Con which quickly go from 1 to 10 in terms of complexity; where only the smartest of developers can remember all of the rules and the exceptions to leverage modern day C++. I feel as if the movers and shakers of the C++ language spec have an inner social circle and have lost touch with the wider developer audience.

Having used C#, Actionscript, LUA, Python and dabbled just enough in Swift and Rust, I believe that C++ either needs to have a fundamental change to break the axiom of backwards compatibility or it will be replaced by Rust, Go, or some other (LLVM) language that has been inspired by C/C++ but has a simpler, consistent syntax made for modern day computing.

My prediction: when underlying, low-level OS components are replaced with non-C, non-C++ counterparts, that will be the beginning of a global acceptance for a new language standard. Until then there will always be a place for C/C++. I really hope this change happens in the next ten years; I'm not holding my breath though.

Re:There are no 'Really Terrible Languages', ...

[russotto]

There are no 'Really Terrible Languages', just 'Really Terrible Programmers'

In addition to C++, there's PHP, Javascript, APL, Ada, and BASIC. Off the top of my head and not including novelty languages. (Also leaving off COBOL and pre-66 FORTRAN because nobody could know better then)

Accreted, not designed.

[jcr]

Aside from the fact that C++ is a steaming pile of needless complexity, the worst thing about it is the brain damage it does to coders who become proud of memorizing the minutia of said steaming pile, believing that this is equivalent to engineering skill.

-jcr

Re:C++ appeals to lovers of complexity

[jcr]

C is not too bad by itself,

Well, aside from its lack of strings and arrays being the cause of the vast majority of security issues for the last several decades...

-jcr

For certain values of terrible.

[AnotherBlackHat]

C++ is, IMO, terrible.

I hate that it allows polymorphism. Worse, it makes people think that polymorphism is a desirable feature that helps create clear, readable code.

It encourages the creation of functions that operate on classes instead of on generic data types.
For example, if a C++ program has a "car" class that include the elements "miles" and "gas" a C++ programmer is likely to create a function
car::calc_mpg() which requires (seemingly) no arguments, rather than the more generic calc_mpg(int miles, int gas)
The problem is, the first is not reusable, and depends heavily on knowledge of the car class.

It encourages inheritance, which fundamentally breaks the box-model (a.k.a. the black-box-model) of programming.
Rather than breaking things into discrete, understandable chunks, it encourages massive classes that must be understood in their entirety.

Then there's operator overloading, code that can be executed before main(), putting code in unexpected places... I could go on, but I think you get the idea.

The main problem is, C++ adds stuff with the unjustified expectation that more stuff automatically mean better.
Sometimes more stuff is worse.

Re:For certain values of terrible.

[AnotherBlackHat]

Anyone who writes the way you described has a very poor understanding of OOP.

No TRUE C++ programmer would ever program that way, eh?

All the basic features of C++ (inheritance, polymorphism, classes, and objects) make writing large systems MUCH easier than they would be without those features.

I've seen this kind of claim many times - and yet, the evidence is that C++ programs aren't any better that ADA, or even FORTRAN when it comes to writing large systems.

Classes only help when they're built correctly, and C++ encourages lazy people to create them poorly.

GOTO didn't force people to write spaghetti code, but that's what actually happened.

Sure, you can write good code in C++, but what is there in the actual language that encourages it?

Re:Does Crystal have a strong backer like Rust has

[jcr]

Mozilla, one of Silicon Valley's greatest success stories

You're funny.

-jcvr

Re:Obcious

[jcr]

Nope, C++ wasn't designed at all: it was accreted.

-jcr

I rememberâ¦

[Dixie_Flatline]

So around 15 years ago, when I was starting my career in the games industry, there was a post here on slashdot about how someone had finally proven that the language did not have a bad recursion in it. In the comments was a programmer who I think may have been working at Microsoft talking about how every compiler programmer would go into writing a C++ compiler excited to be the first one that implemented the full language specification and having the Hope slowly beaten out of them, until they finally arrived on a sufficient compromise. And so compilers would all implement their own specific subset of the language and there was virtually no cross compatibility.

So the language started as an unimplementable mess of a spec, and unless someone has been doing some very hard work to make the language LESS complex, I greatly suspect that it has stayed that way, despite the smattering of quality of life upgrades that have been thrown to us.

In my mind, the greatest sin will always be template metaprogramming, a discoveredâ"not plannedâ"feature that was the consequence of a problem that should not have existed in the first place. They planned poorly in the beginning, threw some more bad planning on top, and ended up with a monumental clusterfuck that will be obfuscating codebases until the end of time.

tl;dr Yes, goddamnit.

Simplicity vs Brevity

[stevestyle]

I used to code on Delphi, based on Pascal, but also did some C++. The main difference I found was that if I made an error in Delphi the compiler found it and the big fix cycle was a few seconds. In C++ the compiler would find a way to interpret my code (as something I hadn't intended) and I would only find the error in unit test, with a big fix cycle of minutes. The benefit of C++ was that you could do ten things in one line. So Delphi was simpler and more verbose, C++ was briefer. But coding in Delphi was an order of magnitude faster.

Re:Yes - Bless You

[NReitzel]

When one hires chimpanzees to write code, one gets code written by chimpanzees. No language tool will make up for lack of understanding. The more flexible a tool, the easier it is to write code that is simply horrid. To turn around and blame the language is disingenuous at best and at worst, promulgates the idea that good code is easy and within the grasp of just any old person.

Anyone can play a scale on a piano. Anyone can figure out what the notes on the music mean. That does not mean that anyone can play Frédéric Chopin's Minute Waltz. More to the point, a "better" piano won't fix this.

Re:Does Crystal have a strong backer like Rust has

[Bruce Perens]

Consider what Linux was at the start, and what it is now. That's how Open Source works. I think the quality of the language will assure its growth, as Linux grew from the hobby project of a pimply computer science lecturer at a Helsinki college whose wife is much more macho than him (she's a martial arts champ), to the OS behind an industry. It happens there is a company behind the Crystal developers. But they are a small team, and they collect money donations from the public.

Re:Yes - Bless You

[dgatwood]

Yeah, as I always have said:

• The nice thing about making programming easy is that any idiot can write software.
• The bad thing about making programming easy is that any idiot can write software.

A good craftsperson does not blame the tools — not because you could hand that person terrible tools and get the same results as with great tools, but rather because the person would know what various tools do well, and would find ways to work within their limitations to create something good.

The same is true for programming languages. Different languages are good at different things. I'd rather smash my head repeatedly with a ball-peen hammer than deal with giant steaming piles of templates, but stick embedded C++ in the kernel without all that STL baggage or exception handling or multiple inheritance or RTTI or any of the other junk that makes the C++ runtime so bloated, and you end up with a halfway decent language for writing device driver stacks.

Need to use piles of regular expressions for some reason? Perl.

Need a lightweight template-based web backend language for a small-ish website? PHP.

Need a language for writing client code? Objective-C.

Need a language for writing enterprise-scale server code? Java.

Need a language for full-stack development by a single development team? Javascript, but don't do that. Really. Don't do that.

And so on.

Not Horrible, Just Mature

[Roger W Moore]

C++ is horrible. Just stating the obvious.

It's not horrible it is just mature. Good languages, like C++, start off with a very clear syntax that greatly simplifies some important programming tasks. As people get more familiar with the language they identify new programming patterns which the language cannot handle well and so new syntax or features are added leading to bloat.

C++ has been around for a while and has had lots of new things added to it making it a mature language. At some point, someone will come up with a new, general purpose language that incorporates many of the advantages of C++ in a coherent syntax and which is useful for lots of people and not aimed at just developing just games, or web, or any other specialized function and then the cycle will repeat.

STL & Boost

[jklappenbach]

As far as I'm concerned, the language went off a cliff when it started incorporating elements of STL in its basic definitions. One good example of this is the ranged for loop, introduced in C++11, which requires iterators that conform to APIs established in the STL. IIRC, these are statically bound to the for operator, which prevents developers from leveraging inheritance and polymorphism when designing their own iterators.

STL was a great improvement in its day, but I haven't been a fan for years, nor for Boost. Both are often cryptically written, poorly documented, and overly abstracted compared to modern frameworks. But, instead of improving on these standards with lessons learned from more recent efforts with languages and development kits, the C++ standards committee has doubled down on antiquity.

I haven't looked back.

Re:Firefox is starting to use Rust

[Ultra64]

I doubt it.

Linus Torvalds:

I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations.

To anyone who wants to build their own kernel from scratch, I can just wish them luck. It's a huge project, and I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting), and anybody who thinks that the choice of language simplifies those things a lot is likely to be very disappointed.

C++ is fine as long as...

[JustNiz]

C++ is fine as long as you stay at a feature level before C++11 and don't use STL (well maybe simple use of containers like string a vector are OK but definately stop there).

Pascal? Now wait a minute ...

[vrassoc]

You're welcome to relegate Pascal to the equivalent bin as COBOL, when there is another language that offers what Free Pascal and its corresponding Lazarus IDE offer: cross-platform RAD resulting in lightning fast native executables on more platforms than any other development solution that I know of - all of it at no cost.

What's wrong with pascal

[lucasnate1]

Why is COBOL and C++ compared with Pascal? The first are languages with problems that were once popular and are now legacy with plenty of good positions. Pascal existed mostly in schools.

Re:Obcious

[theweatherelectric]

So... just like most people's criticisms of C++ then?

No.

Re:Obcious

[thegarbz]

So... just like most people's criticisms of C++ then?

C++ has moved since the 1990s, too.

Yes except exactly backwards. Much of the problems of C++ is how it has moved since the 1990s.