The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases where they interact. Then the "solutions" for those edge cases usually add even more complexity. Worse, they force programmers to coddle their compilers. The ratio between what a C++ compiler will accept and what it will produce sane code for is huge. That's why every C++ codebase I've ever seen is full of code to do things that shouldn't be necessary, and goes through all sorts of contortions to avoid doing things that should be OK, lest the compiler spew out an un-debuggable mess.
I'm perfectly happy managing my own complexity in C, or avoiding it entirely in Python. C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Every other "systems programming language" from D to Objective-C to Go to Rust to Nim presents a more coherent face to the programmer.
> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security.
Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all.
As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to let go of the old decisions.
(There's always some major and vocal user who has build their entire store around some ancient feature.)
Sure, it's a large and complex language that takes time to master. But I'm interested to hear examples of what you call 'profusion of edge cases'.
> The ratio between what a C++ compiler will accept and what it will produce sane code for is huge.
As is the case for any programming language.
> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security.
C++ is designed by its standards committee... If you know anything about the struggles compiler writers have had with implementing the standard, you'd know the standards committee definitely does not consist of compiler writers! It's really cheap to summarize their efforts as motivated by advancing their own job security if you ask me... I can recommend you to attend a meeting or to read some proceedings to convince yourself otherwise.
C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it.
Personally I'm hoping Rust displaces it from most of these remaining niches but even if it does it will probably happen slowly.
I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this:
* lack of namespaces - all names with long prefix look the same to me
* just text based macros
* no generics
* error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking
* no polymorphism
* ton of undefined behavior (almost the same as C++)
>"C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security."
It's not what a compiler writer would want by any stretch. Having helped write a C++ compiler I can a test to that. I will agree that C is a nice language. It does exactly as you tell it.
The complexity I would say is what you get when you "design by committee"
Web standards have a similar problem they keep growing and getting more complex. Try to write a browser from the ground up these days.
Strongly agree on the inordinate number of features point. Which other mainstream OO language supports dynamic & static dispatch, single & multiple inheritance, interface inheritance via abstract classes, generic types and functions via templates, lambdas, type inference, and operator overloading? Roll that up with C compatibility, a 30 year history of evolution, and the complexity of commonly adopted libraries like STL & Boost, and there's simply no avoiding it. There's a lot of C++ out there, and I'm confident that will pay the bills for years to come for this 50 something 25 year C++ veteran!
C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need.
It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.
Not to do the c vs c++ thing, I too prefer c. For over 20 years actually I have preferred c to c++; all the while learning and enjoying other languages like rust. c still is missing some crucial stuff in my opinion-- there are times where I wish generics existed, and when you tie that to a trait system like in rust it's really a pity to not have something like that in c. Couple that with really great package managers for libraries in other languages, and a coherent way to use the libraries, makes one long for more when working in c; it's really missing great and easy code sharing that so many other languages have at their front and center.
How is Rust less complicated than C++? I don't use it, but from what I read it seems to be even more complicated, and getting even more so with the myriad of features they are adding each release.
I agree that c++ is complex, but remember that while trying to update the language the standard committee is trying not to do breaking changes.
If you can do a greenfield implementation like rust, you don't have the baggage of an installed base, yet.
If you compare c++ to a language that is also around for more that 25 years it starts to make more sense why it is complex. Add to that, that it started as an extension to c, which is the reason why it became popular in the beginning.
Also, zero-cost run-time abstractions.
It is whatever you give priority design-wise, and if you look at what is important in c++ (zero-cost runtime abstractions, control of the resulting code), then ending up with something as complex as the c++ language is hard to prevent.
Lots of posts here frame it like "Yes, it's a bit of a complex language, but the C++ committee has the difficult job of keeping everything backwards compatible, so it's understandable." But that's not the reality. The reality is that they (or Stroustroup) made that decision, and that decision was a mistake.
The correct way to deal with backwards compatibility issues is the way Go does it, namely to write tools to automatically upgrade code to a newer API [1]. And as that smug Google guy explained here [2], they have something like this for C++, too. They just don't bother sharing it with us peasants.
The fundamental mistake of C++ is to religiously keep backwards-compatibility with everything for all eternity. It's so easy to say that backwards-compatibility is a good thing. It's obvious! But ultimately that decision is the reason for all the problems that C++ has.
Apple can't write a tool to properly update automatically between Swift versions today, but according to you, this could have been done in the 80s or 90s for C++ which is notoriously hard to parse...
Backward compatibility with C semantics and tooling was fundamental for C++ success. We wouldn't be having this discussion otherwise as nobody would have used C++.
Tools are great for minor upgrades of APIs and syntax, but key to C++ was compiling with existing system headers (no, realistically you do not want to maintain your own 'fixed' version), and most importantly OS and library ABI.
This comment is far overestimating the capabilities of gofix. And this isn't a denigration of gofix (which is a good idea in general that more languages should copy), it's simply that Go actually really didn't change very much between 2009 (when Go was publicly announced) and 2011 (when Go 1.0 arrived and things stopped changing). It certainly didn't change nearly as much as "idiomatic" C++ has between 1990 and today.
The lesson here is that languages should restrict their backwards-incompatible changes to only those that are amenable to automatic migration via limited gofix-like tools, but that runs counter to your argument that C++ ought to be casting off its C heritage (which I quite sympathize with).
While my pet peeves might be different than the author's I agree that C++
makes you work very hard to keep things simple and produce something that is beautiful. Just "avoid the complexity you don't absolutely need" doesn't really work: some basic things are so fundamentally convoluted that I rather just write idiomatic C because it's simple and doesn't get in my way. I want the language to originate from simple axioms so that I can concentrate on the complexity of the problem I'm solving instead of wasting brain cycles on battling the complexity of the language. I would like to like C++ but its benefits barely zero out the extra hoops.
Author of the blog post here. I think you just made me aware of the true and deeper reason for my discomfort with C++: it's the fact that the convolutions are in the basic things. I am perfectly willing to put up with convolutions, annoyances, bugs, weaknesses etc. in anything I use, be it a programming language, a piece of software, a gadget, whatever. Nothing is perfect, and who am I to criticize others for the imperfections in their work. What annoys me is when the annoyances are in the basic things, in the most commonly used features. Make the basic things reasonably good, and keep the crap off to the side.
Well, most of his points regarding complexity are not C++ specific.
The thing with equals applies to most languages that allow to redefine operators.
Even Java has gotten quite complex, I bet he would have quite an hard time succeeding at one of those quiz questions certifications (SCJP and friends).
And simplicity can also turn into more complexity, manual memory management in C vs C++, "templates/generics" in Go, libraries to work around language limitations in JavaScript (npm, yeoman, gulp, grunt, webpacker all at the same time).
In my experience this disease afflicts more than just some C++ programmers, the immaturity is boundless. I’ve noticed some colleagues even think there must be something wrong if code looks simple.
Yes, C++ is a complex language. Yes, it has a ton of warts if you know where to look. But, you can write beautiful software with it, and it can even look beautiful too.
Yes, there are alternatives, but when it comes to performance, expressiveness and actual deployability, C++ is pretty awesome.
Meh. The performance is almost never worth the huge complexity jump. Instead, profile an app in a higher level language and if any part's too slow, implement that in C/C++. That'll quite often be a low, single digit percentage of the app. Get the performance for substantially less engineering/maintenance cost.
Part of the problem here is that OO sits nicely with references, but C++ (like C) is a value based language. This can be seen clearly in most of the design of the standard library -- it's all value semantics, and as such relatively simple and obvious to use (so long as you're not trying to cram OO into it).
A line like
if ( a == b )
In C++ is pretty obvious what it does. It'll always be a value comparison, and if a and b are pointers to objects you are comparing the object identities and not their values. The meaning is exactly the same in Java of course, but the fact you're dealing with pointers is hidden so you generate a lot of confusion about the correct use of `==` and `.equals`.
The author certainly isn't wrong about a culture of complexity in certain elements, but, to be hones, I see that everywhere else too and it needs to be fought wherever it occurs.
Object Pascal, Eiffel, Ada, Mesa/Cedar, Oberon, Modula-2, Modula-3, Oberon, Oberon-2, Oberon07, Active Oberon, Component Pascal, Sather, Swift, D, Go, Rust are OO languages[1] and value based as well.
[1] - As usual, there are many ways of doing OO, not just C++/Java style.
It seems like this article is essentially complaining about the language giving you too much control (e.g. in his copy assignment operator example), when that's exactly what its goal is.
> What does that do? It makes the variable x refer to the object that y is referring to
In Java/C#, it doesn't always:
int x = 1;
int y = 2;
x = y;
The variable `x` does not refer to the object that `y` is referring to(as there is no reference involved at all).
Assignment is a procedure that makes `x` equal to `y` without modifying `y`. However, if `x` refers to `y`, then we can modify `y` after assignment to `x`. This destroys the ability to reason locally about the code, because each object essentially becomes as good as a global variable.
Even though C++ has areas where things gets complicated, this is the one thing that C++ keeps very simple and consistent. There is only one definition of copy, assignment, and equality, whereas in java there is multiple definitions(deep copy vs shallow copy, `==` vs `.equals`).
> That’s called value semantics, although I would prefer the term state semantics: objects do not have a value, they have state, and that’s what’s being transferred here.
No. Its value semantics, as these objects represent some entity. The interpretation of the state(or datum to be more precise) is the known as the object's value. For example, when copying a `std::vector` the internal state of the vector will be different on copy, as it will point to new piece of memory, however, its value will still be the same.
> But experience shows that making a copy of an object is hard.
The compiler already generates a copy constructor and assignment for you. Its only necessary to write one, when one is dealing with low-level pointers. Using the standard built-in types and containers, writing a copy constructor is never needed.
1. Application level: Typically manipulating lots of strings and data massaging. I prefer Java or python for this. The IDEs and eco-system just is so much faster to start with
2. Systems level: Typically a high-performance system like a DB manager or a fast processing library like a message producer etc. These things are time critical and need performance.
I used to really love C++ but I agree, it takes far too long just to start making things run. Sigh!
When I was young, I thought I understood C++, because I had been taught it in school. I did not. Having interviewed several recent graduates who thought they knew C++, I believe this is fairly common, particularly among people with advanced degrees in engineering and the sciences. It's very easy, in C++, not to know the scope of one's ignorance.
The author is relating a personal experience
As a former C++ dev I saw some wonderful code base written in Ç++ and some horrible code base, as any other language. The only specifity Ç++ have in my opinion is that some features have a high learning curve and are not necessary shared with other languages. Once you mastered Ç++ it's easy to move to other languages but it's hard to do the reverse path.
Author here. Quote from the first paragraph of my blog post: "The decision to implement the math backend of GreaterThanZero in Java was driven by other considerations, primarily the appeal of Google App Engine as a hosting platform."
C++ is the only language that is compiled to binary, compatible with many compilers and OS, and can do both low and high level constructs.
It is true that it is a complex language, but this is true for every tool that allows you to do so many different things.
The complexity is not a goal in itself, it's just that it can do all of those things if you need them.
Simple tools are great and will save you a lot of time, but the truth is that you won't always be able to do everything with them. C++ allows you to do everything, and it is true that the cost can be very high and requires a lot of thorough knowledge and expert learning of what happens, but there are projects and cases where you just need to use C++ because that's the only choice you have left.
I agree that an alternatives like rust or D would be great as replacements, but the problem remains: if compilers are not mature on most platform, and if you don't have a large programmer base because the basics of the language are not simple enough, the language won't grow.
>Neither the performance issue that move semantics address nor the perfect forwarding problem exist in classic OO languages that use reference semantics and garbage collection for user-defined types."
I understand reference semantics but what are move semantics?
Author here. A few years back, I wrote an article about the issues that you're asking about. Since the article still comes up as the #1 result of Google search for "C++ rvalue references", I believe it's ok for me to recommend it here:
C++ went off into template la-la land some years back. C++ templates were not supposed to be a programming language. But they turned into one, and not a good one.
Look up the implementation of "max" and "min" in C++ templates.
Now there's a push for "move semantics", to keep up with Rust and the cool kids. But not with language support and a borrow checker. With templates and cute tricks with the type system.
>Rvalue references provide move semantics, and they solve the perfect forwarding problem. Neither the performance issue that move semantics address nor the perfect forwarding problem exist in classic OO languages that use reference semantics and garbage collection for user-defined types.
I don't get this. The performance issue move semantics solve doesn't exist if you just use automatic garbage collection? Is this what the article is saying?
Those specific issues do not obviously exist if the language lacks value semantics. Other issues of course do exist, namely allocation overhead and pointer chasing and the difficulty of doing escape analysis.
I think it depends on where you sit on the stack. A library can take a lot of the complexity away from the higher levels in C++ code. The user code can look fluent and understandable. On the implementation side of the library being used(depending on where it sits in abstraction) is where some ugly complexity shows. But this also generally reflects the competence of the authors.
I think there's a "sweet spot" in complexity (at least for software): too complex gets rejected, but being too simple lacks traction. I think artifacts like C++ memetically infect the brain better than a more elegant PL might, exactly because they require you to think about them a lot, but you can still get things done and not be (totally) overwhelmed.
Isn't there anyway some of a pendant to Conway's law in this? I mean, C++'s standard library is - or at least used to be - rather complex, so the people that would go there and use C++ for their project - would more likely than not - carry at least some of that complexity over into the project...
Does anybody know a good tutorial or book for learning modern C++ 17, focused on best practices (new language paradigms, TDD/BDD, etc.) ? Something like Michael Hartl's Ruby on Rails Tutorial
1. How cumbersome a language is to use (as a beginner, as a confident developer, etc).
- C++ is rather easy to start, but takes ages to master and surprises even powerful users daily.
- Rust is hard to start, it states complexity of systems upfront in a tightly packed knot that should be handled all at once, but once you're past that, it's rather consistent.
- Haskell is very hard to start with, it is basically unlearning every imperative habit, but again, after that it's a powerful and mostly consistent tool (not without its warts, but drastically less than C++). There is some tolerance of complexity in the ecosystem, but it is clearly encapsulated in libraries and justified by papers and research interests.
2. How complex is the abstract core of a language.
- Haskell has had an amazingly simple, elegant and consistent core for decades; on the other hand, modern Haskell has accumulated a lot of research-y stuff (which is still optional to use), which may be nice/cumbersome depending on the situation. Run-time behavior feels woefully underspecified though, and can be flaky and hard to reason about.
- the mental model of Rust is bigger and more complex than in Haskell (traits, generics, lifetimes/onwership, the underlying C-like memory model), but it's definitely practical (if somewhat spartan) and consistent.
- C++ does not have a coherent vision at all: it is a pile of organically grown features with interesting (and sometimes useful) interactions. This pile is outright impossible to reason about formally.
The only definition in which "C++ is not more complex" is the definition of being easy to use for a beginner in the language.
Having used c++ for many years, this does not come across as a ringing endorsement for looking into Haskell or Rust.
I'm quite happy with my current gig using Go. Looking back, the culture of complexity surrounding c++ is obvious, but talking with my peers who have only ever done c++ - it's like they have Stockholm Syndrome.
C++ is not more complex than its competitors like <insert two languages that have little in common yet C++ can be considered competition to both of them because it is such a complex beast>
notacoward|8 years ago
I'm perfectly happy managing my own complexity in C, or avoiding it entirely in Python. C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Every other "systems programming language" from D to Objective-C to Go to Rust to Nim presents a more coherent face to the programmer.
WalterBright|8 years ago
Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all.
As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to let go of the old decisions.
(There's always some major and vocal user who has build their entire store around some ancient feature.)
For example, why does C++ still support EBCDIC?
clishem|8 years ago
> The ratio between what a C++ compiler will accept and what it will produce sane code for is huge.
As is the case for any programming language.
> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security.
C++ is designed by its standards committee... If you know anything about the struggles compiler writers have had with implementing the standard, you'd know the standards committee definitely does not consist of compiler writers! It's really cheap to summarize their efforts as motivated by advancing their own job security if you ask me... I can recommend you to attend a meeting or to read some proceedings to convince yourself otherwise.
cageface|8 years ago
Personally I'm hoping Rust displaces it from most of these remaining niches but even if it does it will probably happen slowly.
oselhn|8 years ago
* lack of namespaces - all names with long prefix look the same to me
* just text based macros
* no generics
* error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking
* no polymorphism
* ton of undefined behavior (almost the same as C++)
anfilt|8 years ago
It's not what a compiler writer would want by any stretch. Having helped write a C++ compiler I can a test to that. I will agree that C is a nice language. It does exactly as you tell it.
The complexity I would say is what you get when you "design by committee"
Web standards have a similar problem they keep growing and getting more complex. Try to write a browser from the ground up these days.
osullivj|8 years ago
api|8 years ago
It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.
pjmlp|8 years ago
They have a ton of warts regarding annotations, usually worked around by using templates, because on that case they are inferred.
The semantics of shared are still being worked on.
The way const/immuatable works, makes some devs just give up and remove them from their code.
I can equally tell some Objective-C issues.
Yes, in general they are better than C++, but not without their own warts.
viperscape|8 years ago
jejones3141|8 years ago
If that were the case, the Edison Design Group (https://en.wikipedia.org/wiki/Edison_Design_Group) wouldn't exist. It exists because compiler writers don't want to have to deal with parsing C++.
(Then there's Dinkumware, which serves the same purpose for library functions.)
mikevm|8 years ago
hux_|8 years ago
The real world is complex. Don't confuse hiding complexity with minimizing complexity.
bjorn2k|8 years ago
It is whatever you give priority design-wise, and if you look at what is important in c++ (zero-cost runtime abstractions, control of the resulting code), then ending up with something as complex as the c++ language is hard to prevent.
IshKebab|8 years ago
ndh2|8 years ago
The correct way to deal with backwards compatibility issues is the way Go does it, namely to write tools to automatically upgrade code to a newer API [1]. And as that smug Google guy explained here [2], they have something like this for C++, too. They just don't bother sharing it with us peasants.
The fundamental mistake of C++ is to religiously keep backwards-compatibility with everything for all eternity. It's so easy to say that backwards-compatibility is a good thing. It's obvious! But ultimately that decision is the reason for all the problems that C++ has.
[1] https://golang.org/cmd/fix/
[2] https://www.youtube.com/watch?v=tISy7EJQPzI
blub|8 years ago
gpderetta|8 years ago
Tools are great for minor upgrades of APIs and syntax, but key to C++ was compiling with existing system headers (no, realistically you do not want to maintain your own 'fixed' version), and most importantly OS and library ABI.
kibwen|8 years ago
The lesson here is that languages should restrict their backwards-incompatible changes to only those that are amenable to automatic migration via limited gofix-like tools, but that runs counter to your argument that C++ ought to be casting off its C heritage (which I quite sympathize with).
yason|8 years ago
thebear|8 years ago
AnimalMuppet|8 years ago
Also note that almost all C code is legal C++, so when you "just write idiomatic C", you're still writing C++. (Perhaps not idiomatic C++...)
pjmlp|8 years ago
The thing with equals applies to most languages that allow to redefine operators.
Even Java has gotten quite complex, I bet he would have quite an hard time succeeding at one of those quiz questions certifications (SCJP and friends).
And simplicity can also turn into more complexity, manual memory management in C vs C++, "templates/generics" in Go, libraries to work around language limitations in JavaScript (npm, yeoman, gulp, grunt, webpacker all at the same time).
ajeet_dhaliwal|8 years ago
ioquatix|8 years ago
Yes, there are alternatives, but when it comes to performance, expressiveness and actual deployability, C++ is pretty awesome.
lallysingh|8 years ago
HumanDrivenDev|8 years ago
I've never had to go looking to find warts in C++.
KayEss|8 years ago
A line like
In C++ is pretty obvious what it does. It'll always be a value comparison, and if a and b are pointers to objects you are comparing the object identities and not their values. The meaning is exactly the same in Java of course, but the fact you're dealing with pointers is hidden so you generate a lot of confusion about the correct use of `==` and `.equals`.The author certainly isn't wrong about a culture of complexity in certain elements, but, to be hones, I see that everywhere else too and it needs to be fought wherever it occurs.
pjmlp|8 years ago
[1] - As usual, there are many ways of doing OO, not just C++/Java style.
luk32|8 years ago
(a==1 && a==1 && a==3)
Evaluate to true.
It is reasonable to assume what you say, but don't say "always", when it's not.
tines|8 years ago
pfultz2|8 years ago
In Java/C#, it doesn't always:
int x = 1; int y = 2; x = y;
The variable `x` does not refer to the object that `y` is referring to(as there is no reference involved at all).
Assignment is a procedure that makes `x` equal to `y` without modifying `y`. However, if `x` refers to `y`, then we can modify `y` after assignment to `x`. This destroys the ability to reason locally about the code, because each object essentially becomes as good as a global variable.
Even though C++ has areas where things gets complicated, this is the one thing that C++ keeps very simple and consistent. There is only one definition of copy, assignment, and equality, whereas in java there is multiple definitions(deep copy vs shallow copy, `==` vs `.equals`).
> That’s called value semantics, although I would prefer the term state semantics: objects do not have a value, they have state, and that’s what’s being transferred here.
No. Its value semantics, as these objects represent some entity. The interpretation of the state(or datum to be more precise) is the known as the object's value. For example, when copying a `std::vector` the internal state of the vector will be different on copy, as it will point to new piece of memory, however, its value will still be the same.
> But experience shows that making a copy of an object is hard.
The compiler already generates a copy constructor and assignment for you. Its only necessary to write one, when one is dealing with low-level pointers. Using the standard built-in types and containers, writing a copy constructor is never needed.
NTDF9|8 years ago
1. Application level: Typically manipulating lots of strings and data massaging. I prefer Java or python for this. The IDEs and eco-system just is so much faster to start with
2. Systems level: Typically a high-performance system like a DB manager or a fast processing library like a message producer etc. These things are time critical and need performance.
I used to really love C++ but I agree, it takes far too long just to start making things run. Sigh!
sevensor|8 years ago
int0x80|8 years ago
Most of the time this only shows the lack of deep knowledge on the language.
neo2006|8 years ago
airstrike|8 years ago
thebear|8 years ago
jokoon|8 years ago
It is true that it is a complex language, but this is true for every tool that allows you to do so many different things.
The complexity is not a goal in itself, it's just that it can do all of those things if you need them.
Simple tools are great and will save you a lot of time, but the truth is that you won't always be able to do everything with them. C++ allows you to do everything, and it is true that the cost can be very high and requires a lot of thorough knowledge and expert learning of what happens, but there are projects and cases where you just need to use C++ because that's the only choice you have left.
I agree that an alternatives like rust or D would be great as replacements, but the problem remains: if compilers are not mature on most platform, and if you don't have a large programmer base because the basics of the language are not simple enough, the language won't grow.
steveklabnik|8 years ago
bogomipz|8 years ago
>Neither the performance issue that move semantics address nor the perfect forwarding problem exist in classic OO languages that use reference semantics and garbage collection for user-defined types."
I understand reference semantics but what are move semantics?
Also what is the "perfect forwarding problem"?
thebear|8 years ago
http://thbecker.net/articles/rvalue_references/section_01.ht...
Warning: Read only if you have a serious interest in C++.
unknown|8 years ago
[deleted]
Animats|8 years ago
C++ went off into template la-la land some years back. C++ templates were not supposed to be a programming language. But they turned into one, and not a good one.
Look up the implementation of "max" and "min" in C++ templates.
Now there's a push for "move semantics", to keep up with Rust and the cool kids. But not with language support and a borrow checker. With templates and cute tricks with the type system.
andrepd|8 years ago
I don't get this. The performance issue move semantics solve doesn't exist if you just use automatic garbage collection? Is this what the article is saying?
gpderetta|8 years ago
beached_whale|8 years ago
humanrebar|8 years ago
carapace|8 years ago
mar77i|8 years ago
unknown|8 years ago
[deleted]
petters|8 years ago
x = y;
behaves the same if the types are int and vector<int> (unlike e.g. Java and Python).
sireat|8 years ago
geoffroy|8 years ago
commandlinefan|8 years ago
otabdeveloper1|8 years ago
dmytrish|8 years ago
1. How cumbersome a language is to use (as a beginner, as a confident developer, etc).
- C++ is rather easy to start, but takes ages to master and surprises even powerful users daily.
- Rust is hard to start, it states complexity of systems upfront in a tightly packed knot that should be handled all at once, but once you're past that, it's rather consistent.
- Haskell is very hard to start with, it is basically unlearning every imperative habit, but again, after that it's a powerful and mostly consistent tool (not without its warts, but drastically less than C++). There is some tolerance of complexity in the ecosystem, but it is clearly encapsulated in libraries and justified by papers and research interests.
2. How complex is the abstract core of a language.
- Haskell has had an amazingly simple, elegant and consistent core for decades; on the other hand, modern Haskell has accumulated a lot of research-y stuff (which is still optional to use), which may be nice/cumbersome depending on the situation. Run-time behavior feels woefully underspecified though, and can be flaky and hard to reason about.
- the mental model of Rust is bigger and more complex than in Haskell (traits, generics, lifetimes/onwership, the underlying C-like memory model), but it's definitely practical (if somewhat spartan) and consistent.
- C++ does not have a coherent vision at all: it is a pile of organically grown features with interesting (and sometimes useful) interactions. This pile is outright impossible to reason about formally.
The only definition in which "C++ is not more complex" is the definition of being easy to use for a beginner in the language.
tomohawk|8 years ago
I'm quite happy with my current gig using Go. Looking back, the culture of complexity surrounding c++ is obvious, but talking with my peers who have only ever done c++ - it's like they have Stockholm Syndrome.
setzer22|8 years ago