Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ and the Culture of Complexity (2013)

blog.greaterthanzero.com

Post reply on HN
Print view View original

31–40 of 285 posts

Re: C++ and the Culture of Complexity (2013)

#31

Post by overgard »

lallysingh wrote: post #6
ioquatix wrote: post #4

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.

I used to argue the same thing, but passing things across language barriers makes debugging painful and is usually pretty error prone, tools can't understand your codebase as well, and there are performance costs to all the conversions.

Re: C++ and the Culture of Complexity (2013)

#32

Post by WalterBright »

pjmlp wrote: post #25
notacoward wrote: post #16

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…

Regarding D, it looks like that, but any big code base enjoys meta-programming (mixins), templates. 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. Y…

> The way const/immuatable works, makes some devs just give up and remove them from their code.

That's true. The thing with D const/immutable is they are transitive, and the compiler means it. It's not a suggestion.

The advantage of enforced transitive const/immutable is, of course, is it's foundational if you want to do functional style programming.

Re: C++ and the Culture of Complexity (2013)

#33

Post by bogomipz »

The author states:

>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"?

Re: C++ and the Culture of Complexity (2013)

#35

Post by WalterBright »

convolvatron wrote: post #29
api wrote: post #21

Earlier quoted context omitted.

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.

just a contrary opinion. I read the c++ book in the very early 90s. someone told me it was the future of programming. every single c++ shop I've worked at since has said, 'well, yes the language is a mess, but if you stick to a well controlled subset, its really pretty good' and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so…

> and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so I guess the 'sane subset' argument is ok in theory, but really not in practice.

To be fair, this happens with every language I've been associated with, even C. Just look at those people who do metaprogramming with the C preprocessor. It's madness!

I used to do that too, as a young programmer. It took about 10 years to grind that out of me. One advantage of us older programmers is we show how clever we are by writing amazingly simple and understandable code. :-)

Re: C++ and the Culture of Complexity (2013)

#36

Post by WalterBright »

foo101 wrote: post #7
lallysingh wrote: post #6

Earlier quoted context omitted.

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.

C++ is a complex language no doubt. But software written in C++ need not be complex. Java, on the other hand, is a simple language. But the kind of unnecessary complexity I have seen in Java-land (EJBs, Spring, etc.) has no parallel in the C++-land. So going by your argument, I would choose C++ over Java to avoid the complexity jump, then profile the app, and if any part's too slow, improve that again in C++.

Java just pushes the complexity into the user's code. For example, a friend of mine once gushed to me about Java IDEs - with one click of a button, a hundred lines of boilerplate are automatically added!

I replied a good language shouldn't need boilerplate code automatically inserted.

Re: C++ and the Culture of Complexity (2013)

#37

Post by KayEss »

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.

Re: C++ and the Culture of Complexity (2013)

#38

Post by thebear »

bogomipz wrote: post #33

The author states: >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"?

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:

http://thbecker.net/articles/rvalue_references/section_01.ht...

Warning: Read only if you have a serious interest in C++.

Re: C++ and the Culture of Complexity (2013)

#39

Post by hux_ »

notacoward wrote: post #16

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…

Oh give me a break. Following this logic, why aren't you writing your code in English?

The real world is complex. Don't confuse hiding complexity with minimizing complexity.

Re: C++ and the Culture of Complexity (2013)

#40

Post by pjmlp »

KayEss wrote: post #37

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 a…

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.

Post reply on HN