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

151–160 of 285 posts

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

#151

Post by Chathamization »

Santosh83 wrote: post #69
WalterBright wrote: post #30

Earlier quoted context omitted.

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

THIS is the reason IMO too. C++ has taken on the very difficult task of remaining broadly compatible with C and with legacy features while at the same time has continuously evolved over the decades, incorporating whatever was the state of the art at that time, without new features breaking old code. That is not an easy task without increasing complexity.

> incorporating whatever was the state of the art at that time

State of the art or flavor of the month? For instance, the features from functional programming that C++ and Java recently (in the last decade) added weren't anything new. When functional programming started to become more popular was when their features started showing up in C++ and Java.

If people are concerned that your language is already to large than adding elements from other programming paradigms because they're suddenly what's hot doesn't seem like a great idea. It feels like some languages are chasing the crowd, which can lead to a messy language ("OOP is all the rage now? Our language is all about OOP! Oh, functional is all the rage now? Well, we just nailed on some functional features!").

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

#152

Post by ska »

blub wrote: post #148
notacoward wrote: post #124

Earlier quoted context omitted.

> Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. Yeah, after I wrote that I realized it wasn't quite right. C++ is designed by compiler-writer wannabes . Architecture astronauts[1] on standards committees. They think they understand how compilers should work, and that adding support for this or that should be easy. "You just need to..." is their fav…

You can assure us based on what? If you have insider knowledge or particular credentials please share. So far it looks like you're ranting.

  "I can assure you this is not true at all."
Was quoted, not the user you are replying to.

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

#153

Post by the_af »

otabdeveloper1 wrote: post #125
setzer22 wrote: post #90

Earlier quoted context omitted.

C++ is not more complex than its competitors like

What they have in common is a complex compile-time static typing system. The source of complexity isn't a mythical "culture of complexity", the complexity is there because it's inevitable if you want to implement powerful compile-time type reasoning. (And you definitely want compile-time reasoning because it's the only way to guarantee performance and correctness of programs.) The case of Haskell and Rust proves that…

What exactly do you mean by "a complex compile-time static typing system"? I'm not familiar with Rust, but C++'s and Haskell's typing systems don't look very similar, or even of similar complexity.

I do agree there's an inherent complexity in the problem domain. It's just that some languages are more helpful than others in dealing with this complexity :)

PS: my own bias: Haskell's seems both easier (in general) and more helpful than C++'s.

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

#154

Post by TheOtherHobbes »

Santosh83 wrote: post #69
WalterBright wrote: post #30

Earlier quoted context omitted.

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

THIS is the reason IMO too. C++ has taken on the very difficult task of remaining broadly compatible with C and with legacy features while at the same time has continuously evolved over the decades, incorporating whatever was the state of the art at that time, without new features breaking old code. That is not an easy task without increasing complexity.

It's true that isn't easy.

It's also true that it may not be necessary.

What makes a good language? One that randomly accumulates state of the art ideas about programming without breaking old code, or one that gets out of the way and allows requirements to be expressed reliably and relatively simply?

Of course C++ is used because it's fast. It's fine in limited domains like DSP.

But what is the rationale for a language that whimsically accumulates new features every couple of years, while failing to deal with basic challenges like memory management?

It's not as if it's ever going to reach a critical mass and turn into Haskell.

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

#155

Post by [deleted] »

notacoward wrote: post #124
WalterBright wrote: post #30

Earlier quoted context omitted.

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

> Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. Yeah, after I wrote that I realized it wasn't quite right. C++ is designed by compiler-writer wannabes . Architecture astronauts[1] on standards committees. They think they understand how compilers should work, and that adding support for this or that should be easy. "You just need to..." is their fav…

[deleted]

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

#156

Post by gpderetta »

oblio wrote: post #147
jVinc wrote: post #91

Earlier quoted context omitted.

Looking at the current programming language space, it honestly doesn't look like the Python 2/3 issue hit them that hard in the long run. And while it wasn't popular it might have been the right way forwards. Python is one of if not the most rapidly growing language. In large part due to the data-science movement which for anyone I've talked to is based on Python 3. I still occasionally talk to 2.7 proponents, who ex…

I know I'm in dangerous territory here, but what if the C++ community, as in committee, compilers, etc., pull a Javascript strict mode? Basically subsequent C++ compilers provide the possibility of some subset of C++ which is considered modern. Then files can be marked with it, at which point the C++ compilers reject deprecated idioms. Over time this should take over, I think most of the JS in the wild is now using s…

The header inclusion model (where you will be textually including hundreds of thousand lines of random code in a translation unit) doesn't make it easy to have version flags.

Also many of the issues are intrinsic to the way the language has evolved (the template compilation model for example), it is not just a matter of deprecating a few features here and there (although that might help)

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

#157

Post by jhasse »

masklinn wrote: post #61
mikevm wrote: post #48

Earlier quoted context omitted.

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.

> How is Rust less complicated than C++? In pretty much all senses of the word? > getting even more so with the myriad of features they are adding each release. It's far from adding a "myriad of features" with each release, and most of those it adds are library stuff, see for 1.23: https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... And with respect to non-library features currently in-flight, by and larg…

> pointer lifetime issues don't exist any less in C++, the only difference is the compiler doesn't help you with them.

There's also the case though where the Rust compiler isn't helping you, but is just wrong.

Must of them are going to be fixed by non-lexical lifetimes soon though.

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

#158

Post by 72deluxe »

gpderetta wrote: post #117
pjc50 wrote: post #116

Earlier quoted context omitted.

> why does C++ still support Stop right there! There is plenty of evidence that removing features from a language is fatal to adoption. Both Perl and Python have suffered from this. Specifically for trigraphs (apart from these, EBCDIC support doesn't affect compilers on other systems) IBM have a vote and they voted not to remove it: https://isocpp.org/files/papers/N4210.pdf

IIRC they did lose the final vote though, and trigraphs is one of the few features ever removed from C++.

I miss them - I enjoyed being able to write ??=include at the top of my files.

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

#159

Post by gpderetta »

bjorn2k wrote: post #107
jVinc wrote: post #91

Earlier quoted context omitted.

Looking at the current programming language space, it honestly doesn't look like the Python 2/3 issue hit them that hard in the long run. And while it wasn't popular it might have been the right way forwards. Python is one of if not the most rapidly growing language. In large part due to the data-science movement which for anyone I've talked to is based on Python 3. I still occasionally talk to 2.7 proponents, who ex…

I also would like to drop backwards compatibility in favor for a clean simple language, because I happen to write completely new functionality. If you ask yourself the question: "Do I want to break backwards compatibility in 2020?", then that same question could have been asked in 2003. Which would mean that the language lost traction (at least that is my opinion), because I could not recompile my old code and theref…

Exactly.

There have been plenty of from-scratch languages that are designed as a better C++. Many have died, of those left no one has yet gained significant traction [1].

It is not clear why yet another an incompatible language would be better just because it happens to be called C++. The effort would be better spent on improving one of the existing alternatives.

[1] Plenty of newer languages have had breakaway success, but no language that is meant to be a full C++ replacement has yet. D has passed peak hype without a breakout. Rust might still make it, we will see.

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

#160

Post by edflsafoiewq »

mikevm wrote: post #48
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…

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.

Here's one example:

In C++, creating an instance of a class is fantastically complicated. The class must be initialized, and there is a zoo of different initialization forms: value, direct, aggregate, default, list, copy, etc. Which one foo {} invokes has been the subject of a spec bug. Some of these invoke a constructor, which is like a function, but isn't a function, multiplying the number of concepts involved further. Constructors suffer from bizarre syntactic limitations. They need a special syntax for handling exceptions. The form foo f(); famously declares a function instead of default initializing f. The [dcl.init] section of the spec is about 16 pages long and there are about another dozen about how constructors work in the special member functions section.

In Rust, there is exactly one way to create an instance of a struct: you provide a value for each of its fields.

Post reply on HN