Slashdot Mirror
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?"
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?"
Nope.
People who don't understand C++ are doomed to recreate it, badly.
No sig today...
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
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.
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.
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.
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.
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++.
No sig today...
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.
Your ad here. Ask me how!
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 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:
Bruce Perens.
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
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.'
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. :)
If you're a zombie and you know it, bite your friend!
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.
It's a worthy conceptual child of PL/1.
C++ is one reason why I gave up programming and became a prostitute.
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/...
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.
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.
No sig today...
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.
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.
There is nothing saying you have to use every bit of it.
Other than the guy you inherited the codebase from.
http://michaelsmith.id.au
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.
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.
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.
Ezekiel 23:20
Nope, C++ wasn't designed at all: it was accreted.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
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.
The discussion is moot when it involves inherited codebases. You are compelled to use the tools already selected whether you like them or not.
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.
Don't take life too seriously; it isn't permanent.
Yeah, as I always have said:
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
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.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Linus Torvalds:
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.
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.