Why is C++...

...so bad? Why does it have such a bad reputation?

I'm an experienced C++ programmer and, while the language has warts, I can't understand the reason for the enormous amount of criticism against the language.

I'd like to hear the honest opinions of /prog/rammers in this regard.

>>74

But why "optimized" in straight contrast with "flexible and generic"? Specially, why "prematurely" optimized? I see these design decisions as simply the most natural, direct and even simple way to implement some functionalities. I don't see them as premature optimizations. For example, I would categorize some ridiculous C++ idioms such as CRTP into the "premature optimization" moniker, but in general, C++'s execution model is just extremely simple, not "prematurely optimized". These decisions are not performance-driven.

Just to illustrate my point, one could argue that garbage collecting, multimethods and other things you've mentioned are just "premature flexibility". I have faced just very few situations in which I really needed things like that, for projects of different nature.

Not that these things are bad, much for the contrary: they're good tools when applied in the correct problems. C++ simply opted not to impute these tools to every program beforehand. And many, if not all, of them can be implemented, nonetheless, in C++, with the particular advantage (if it could be said so) that the programmer knows these things are present in their program, and exactly where they are, if it matters to him. I understand that syntax is not just sugar and, for example, while lambdas cannot be compared with functors, since they're much more expressive and syntactically easy to manipulate, functors usually fill in well the gap lambdas were supposed to fill, and these objects fit even better (in my opinion) with the overall rest of the language. And these features can be implemented in different ways, with different goals in mind. This is a very important degree of "flexibility and genericity", in my opinion, which is often overlooked because they don't come in the shape people are used to.

And lastly, well, C++ surely isn't easy for compilers. It is possibly the most difficult language to parse and to optimize; that's why compilers fail so badly in providing good, human-level responses and results to the user.

>>80
oh wow talk about feminism's greatest invention

>>78
Okay, maybe I wasn't clear enough.
Expert programmers are programmers with good experience,...
... they were proposed along the years by some expert programmers.
I mean, people with good experience naturally avoided common problems and started better designs. Some of these practices were just collected by these authors, so they can't take full credit for this “awesome” TR1.

specific “tastes”.
I consider any individual opinions as a matter of taste. When a group of people has the same taste, then this makes a pattern that could evolve to a future standard taste.

For example, S-expressions in Lisp.
“... a community of S-expression Lisp programmers quickly developed. M-expressions fell into neglect, and were never implemented.” -- http://en.wikipedia.org/wiki/M-expression

>>81
If you don't care about performance right off the bat, there is no reason at all to use C++. If you do care about performance, C++ makes it extremely difficult, if not impossible, to measure in general cases. So the target audience for C++ are projects with well-defined requirements, known in advance, and well-defined use-cases, known in advance. In such cases using a restricted subset of C++ is not unreasonable (though only because nothing else quite applies).

We call them "games."

Lisp is shit.

>>85
How many syntactically equivalent ways do you need to cry more faggot?

>>74
the thing is, C++ basically invented modern, typical OOP.
lol no HIBT?
That title goes to Simula-67. C++ is an evolutionary dead-end spanning straight from Simula-67 with Algol syntax changed to C, multiple inheritance added, GC stripped out, and coroutines ignored, in fact, Stroustrup wrote Cfront because he wanted a Simula with manual memory management. If you look at 1967 language's code it looks like modern OO. All later language designs re-borrowed back giving back GC, single inheritance and almost coroutines.

>>86
Fuck off and die, faggot storm. Lisp is shit.

>>82
I don't think so because this doesn't have anything with political, social or economic, but anatomical equality, which reminds me of female sexists. While I do love women in general, I don't like female sexists.

>>88
I'm already dead. What now, faggot?

>>90
Kill yourself.

"Lisp" stands for "Lisp Is Syntactically Pure"

                __ __
      /    /   /  /_/
     /__  / __/  /

        /  .  \
       /   '   \
      /    |    \
     /           \
    /      |      \

>>93
That was 1993 quality!

Lisp, for me, has always been a place where anything is possible--a refuge, a magical world where anyone can go, where all kinds of people can come together, and anything can happen. We are limited only by our imagination.

"Why is C++?"

why a duck

>>99
wow amazing dubs bro

>>99
nice lv99 dubs bro

check 'em

>>99
>>100
HOLY FUCKING FUCK FUCK DUB DUBS FUCK ME IN MY TIGHT TEEN ASSHOLE I'M CUMMING UNCONTROLLABLY

>>101
sweet, you got me a boner

>>81
I have faced just very few situations in which I really needed things like that, for projects of different nature.

This is called "blub"

For instance, functional code (both in the sense of "avoiding mutation" and "not dysfunctional" -- there is no difference, practically) is exceedingly difficult to write without a garbage collector. Automatic ref-counting in destructors can help, but it doesn't take you all the way there.

>>84
as a professional in the games industry, this kind of makes me rage. It is exactly this kind of attitude (and you have correctly identified its corollary: C++) that is keeping us from making better games. We can't iterate on designs; we have to keep reimplementing the same shitty, inflexible engines over and over.

>>103

He does have a bit of a point in that, the more assumptions are are able to make about the problem you are trying to solve, the more opportunities for optimization there are. One example would be the use of ray casting in wolfenstein 3D. Because all walls in the game were either vertical or horizontal, it was really easy to solve for the intersection point of a ray with a wall. So their limited solution could perform better than a more general solution. However, the limited solution cannot handle the general case of levels with walls that are not all vertical or horizontal. You could try to extend the limited solution until it handles the general solution, but it is likely that it would be more reliable and more productive to just start from scratch again.

>>103
we have to keep reimplementing the same shitty, inflexible engines over and over.
U MENA FROSTBITE?

>>111
Check 'em!

>>103
as a professional in the games industry, this kind of makes me rage. It is exactly this kind of attitude (and you have correctly identified its corollary: C++) that is keeping us from making better games.
It seems like you understood, but just to be clear, I wasn't trying to rag on abstract game programming, only how most in the industry seem to do it. As a gamer of 30 years I agree, things are very stale.

>>83

I understand better what you intended to mean now. However, doesn't it sound paradoxal? That is: if the community has indeed directed the language development, why does the community criticizes it so badly?

I still personally believe that the true C++ community, and the true programming community for that's sake, is totally apart from the people who actually decides things for the language. This must happen in many committees, but this is specially true in the C++ case, because of the problem of the economical interests I've proposed. Anyway, that's only my personal opinion on the matter.

>>84

Nothing could be further from the truth. First, why shouldn't C++ be used by people which don't care about performance? As I stated, C++ wasn't designed with straight performance in mind, but rather implementation simplicity in the lower level. Even in the frontend level, writing a template is not harder than writing a complex C macro which would perform the same task, writing a class hierarchy is not harder than writing the same hierarchy in parallel languages, and applying "expert" techniques and practices is not at all needed to write a good, working piece of code in C++. The lack of libraries, indeed, is an inherent problem, but there are excellent C++ frameworks out there; Qt is one which comes to my mind. The bottom line is, C++ can be (and should be) used by "normal", "non-expert" people.

Second, why does C++ make it much more difficult to properly profile code?

Profiling C++ code is not much different from profiling C code, maybe except in areas where templates are involved -- but templates are usually restricted to some specific parts of the program, mostly containers and special pointer types. Using them in most other situations, as I have stated, is indeed a symptom of premature optimization, and it's comparable, in form and content, to abuse C macros which generate syntax. (Curiously, one can't easily debug or profile easily those macros also: even the compiler will mess up the error message line numbers when compiling a macro which has expanded to invalid code.)

Profiling is, in general, difficult to perform, independently of the language; however, once more, C++ doesn't make it specially harder. Most arguments in this aspect denounce things like, "syntactically one can't know whether a sum operator was overloaded into a O(n2) operation"; however, no sane design does that; no sane design binds semantics to methods and operators too far from what they're subjectively intended to mean, and if the operation is costly, no sane design would hide that fact under a "convenience" disguise. This is not specific to C++ either.

>>103

I understand the need for a garbage collector when writing functional code, and it is legitimate. But the Blub argument, for me, is not.

First of all, the entire idea of people "not knowing they need something", or "not knowing they could use of some other thinking paradigm or technique" is faux. Assembly language programmers know they could use of some more parsing power. C programmers know they could use of some more metaprogramming facilities, or some more object-orientation techniques in some cases. C++ programmers know they could use of some garbage collecting, or some sort of automatic memory management. Java programmers feel the need for proper closures when such a need really appears. People with some experience know what they need, when they need it, even when they're unaware those techniques already exist elsewhere: that's the root cause of the creation of language "idioms" in programming communities. Many newcomers to the programming world quickly "invent" simple data structures, such as linked lists and trees, without having ever touched computer science literature.

Second, pushing "new paradigms" to people is, at the best, an argument against simplicity and minimalism. At the worst, I would say it is an extremely pedantic way of selling "dreams" to people, dreams of developing awesome productivity, or of developing a revolutionary mindset. I go to an extreme and claim that it is even right-winged in the sense that it inevitably culminates on the always implicit idea that "everyone thinks the same, and I'm special because I don't". Not really: people are not completely stupid. Java programmers are not stupid because they don't know all the power Lisp macros offer, or all the power monads and zygomorphisms in Haskell offer, or all the power C++ templates offer. They're not bound to an "inferior" mindset because their language has less "power" (which is, par excellence, an extremely subjective aspect) than others. Needs grow outwards, and are not pushed inwards someone.

Lastly, I'll develop a little this "powerful language" part. A "powerful" programming language to one person is a terrible language to another. Ask Steve Hutchessen or Randall Hyde about assembly programming and they will be quite comfortable to claim it is the most powerful language around, unbeatably. Ask Paul Graham, he'll defend Lisp. Ask Stroustrup, he'll naturally claim for C++. Are they wrong? Are they lying? These people are not stupid, and don't work on simple summer projects. Each one of them does have a strong point to make. Apart this, there always will be people who claim something is better than something else, and will even appeal to intellectually elaborate arguments (such as the Blub argument) in order to convince, or maybe make feel people uncomfortable about the subject. Objectively speaking, each one of the most popular languages have good, clear and mensurable traits, and bad ones also. So does C++, albeit I feel these traits are never brought up to surface precisely due to the amount of bashing between programmers claiming the poison they've picked are better than the others'.

Claiming something is absolutely superior to something else almost immediately proves  not raw stupidity, but rather a degree of narrow-mindedness.

>>108
If you don't know the answers to your own questions, you either haven't used C++ enough, or you haven't used other languages enough. It is hard to say exactly where your fault is.

>>108
I don't believe. While the C++ commitee may be distant from the programming community, programmers could fork their way around if they felt too much suffocated. I agree that Qt is really a good piece of decent C++ software, and that didn't come from the C++ commitee.

Now, about people... I completely disagree. It isn't that people can be dumb sometimes. They are always retards. Myself included. It just happens that humans are very afraid of new experiences, just like the fucking old Myth of the Cave. You can just see here the amount of jokes directed to homossexuality or [dumbproof,enterprise,bloated] languages/softwares.

People with strong wording are just scared blockheads, and try to use (obscure) technical words to put challengers away, just because they are absolutely sure that their knowledge is the truth. Hyde, Graham, Stroustrup, and many others have different point of views because their usages of computers are also different. I can guess they have enough experience to judge what is most appropriate, but depending on the person you're asking, implementing something in CL instead of C++ can be either “done in a weekend with 2-3x slower” or “done in a week and 100-200% faster”, and both can be right, depending on the actual situation.

The only true abomination really is the people that don't go out of the cave and keep blabbering that their choice is way better than yours. How can someone say that coke is better than pepsi if he didn't taste both? But what really makes me mad is that when I try to show these people something they just turn around yelling crap!

(And that explains why “smart” people are: [a] extremely anti-social or [b] almost divinely humble.)

>>110
you can't just judge homosexuals without taking in the ass once?

>>111
you can't just drug addicts without taking in heroin once?

>>111
you can't judge homosexuals without trying Lisp once?

>>111
you can't judge jews without trying Haskell once?

>>>111-114
When you are shithe full of yourself, no.
Sage learns through these unfruitful discussions indeed.

LISP
NOT
EVEN
ONCE

>>108
first off, disregarding Blub is kind of silly. Everyone who has ever said Blub is a real thing does so because they've personally experienced it, myself included (and apparently >>110 as well.) Maybe you're special. But I'll talk about your particular points anyway.

the problem is that those "new idioms" and design patterns tend to form a reputation as harmful or useless or over-engineered, because the language rarely makes it worth it to use them.

For instance, most C programmers hear "macro" and think about Microsoft's shitty macros in their API and other shitty macros they've used. They think, "oh, Lisp programmers must be those guys who write clever macro hacks and confuse everyone. I bet every Lisp DSL is an unreadable mess that only the author can understand, just like C DSLs. I guess Lisp is a toy language and would be harmful in a large project."

The Lisp programmer on the other side is thinking "writing C is such a pain. Its macros are so crappy that I can't even really use them for anything beyond simple little things or else it just turns into a huge mess."

I don't usually consider macros as "important" part of language, more like generic building blocks to save the building time.
You use C macros not to invent a mini-language but to do what macro is intended to do since first assembler macros:
to save typing time. Abstraction level of macro is just a bonus, not something C macros are very good at(its just text juggling).
You could just as well remove or expand macros yourself, with some productivity loss. it won't change a single thing in C.
In Lisp you really need the macros, or the language would feel crippled. Macro extends lisp since the syntax/functionality extension via new functions to macro is trivial: lisp functions are forced to be syntax-free soup of words which can be macroed to infinity with prefix notation: it will just be a stack of macro on top of macro on top of macros....plus its abusing the entire language power at runtime.
If you don't find this unmaintainable and complain about simple C macros which are pristine sights of clarity and simplicity compared to Lisp macros which are using everything to manipulate code(as i understand you can also manipulate string of C code and output it similar to this but the process will be incredibly messy compared to plain C macros(it would be emulating a Lisp interpreter at run-time to construct the final code and compile/execute it) and much longer, so normal C programmers avoid this type of design).

>>118
>I don't usually consider macros as "important" part of language
You use only gotos, because for-loop is a macro?

>>118
it would be emulating a Lisp interpreter at run-time to construct the final code and compile/execute it) and much longer, so normal C programmers avoid this type of design
Blub doesn't allow it, so it must be shit. Perfect logic, moron!