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

141–150 of 285 posts

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

#141

Post by pjmlp »

gpderetta wrote: post #131
pjmlp wrote: post #106

Earlier quoted context omitted.

Well, since Windows 8 .NET store apps don't support JIT, they only run AOT compiled to native. And NGEN is a standard component of the .NET SDK since the beta days. So AOT compilation has been part of the default tooling since ever.

I guess native needs to be qualified. I would say that Native means it speaks the ABI of and fits into a specific platform. I would say that the C family languages are traditionally native of most operating systems [1] as they are polyglot and can directly speak whatever C ABI dialect is used there; they also work with the native platform tools. C# is really native of the .Net platform and although it can be AoT comp…

> Win32 or the interfacing is not seamless

Well then Rust, D, Swift, Go, Rust, Haskell, OCaml are not native by that measure.

C# integration with Win32, COM and UWP (aka COM reborned) is painless comparing with any of them.

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

#142

Post by mannykannot »

clishem wrote: post #18
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…

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

> I'm interested to hear examples of what you call 'profusion of edge cases'.

For one example, look at the profusion of cases in type deduction, depending on whether one is dealing with a value, an array, a pointer, or one of two different references, and whether qualified as const or volatile.

One might argue that these cases are too prevalent to be called 'corner' cases, but that doesn't exactly help! In C++11 and C++14 there was the indisputable corner case where auto and template type deduction differed with regard to braced initializer lists, though in a rare case of backwards-compatibility-breaking, it has now been fixed [1].

Scott Meyers, for one, has given examples of particular cases in the use of braced initialization, especially in the context of templates, that can be considered corner cases in that they are probably not likely to arise very often in most of the C++ code that is being written for applications.

[1] https://isocpp.org/blog/2014/03/n3922

[2] Scott Meyers, 'Effective Modern C++', pp 52-58.

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

#143

Post by pjmlp »

tzhenghao wrote: post #140
pjmlp wrote: post #80

Earlier quoted context omitted.

Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.

There has been recent pushes to use Rust in embedded systems, but I agree it'll take a long time. Check out this blog [1]. [1] - http://blog.japaric.io/

Thanks.

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

#144

Post by pjmlp »

KayEss wrote: post #120
pjmlp wrote: post #40

Earlier quoted context omitted.

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.

There are, but they all have at their core an idea of an object which has identity, which values don't have. You can easily model objects in value languages, but sometimes it isn't so easy to do the other way around (like Java's strings -- Smalltalk had similar problems).

> There are, but they all have at their core an idea of an object which has identity, which values don't have.

Not at all, objects need to be explicitly allocated on heap, otherwise they are value based.

I took care not to list any language that only allows objects as references.

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

#145

Post by athenot »

thebear wrote: post #62
yason wrote: post #59

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

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

This reminds me of a goal Larry Wall for Perl when he was designing it: "make the easy things easy, and the hard things possible".

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

#146

Post by sevensor »

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.

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

#147

Post by oblio »

jVinc wrote: post #91
IshKebab wrote: post #63

Earlier quoted context omitted.

Yeah by keeping backwards compatibility they avoided something like the Python 2/3 mess which I would say is worth the effort and cruft.

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 strict mode.

I can't be the first person to think of this. There must be a reason something like this hasn't gotten traction.

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

#148

Post by blub »

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…

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.

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

#149

Post by gpderetta »

pjmlp wrote: post #141
gpderetta wrote: post #131

Earlier quoted context omitted.

I guess native needs to be qualified. I would say that Native means it speaks the ABI of and fits into a specific platform. I would say that the C family languages are traditionally native of most operating systems [1] as they are polyglot and can directly speak whatever C ABI dialect is used there; they also work with the native platform tools. C# is really native of the .Net platform and although it can be AoT comp…

> Win32 or the interfacing is not seamless Well then Rust, D, Swift, Go, Rust, Haskell, OCaml are not native by that measure. C# integration with Win32, COM and UWP (aka COM reborned) is painless comparing with any of them.

I think Rust and D have seamless integration with C style ABIs. Swift is native on iOS. Haskel and OCaml have, as far as I understand, painful FFIs and a relatively heavy runtime so I wouldn't call them native.

edit: to be clear, using 'compiles to object code' as the definition of Native, is both a misuse of the word, and meaningless as it is a implementation detail that can change easily and bound to be obsolete quickly.

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

#150

Post by ndh2 »

blub wrote: post #139
ndh2 wrote: post #81

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

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

I didn't say that.

It's not the 80s anymore, and the reason that C++ is still and will always remain hard to parse is... backwards compatibility.

Post reply on HN