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

161–170 of 285 posts

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

#161

Post by KayEss »

pjmlp wrote: post #144
KayEss wrote: post #120

Earlier quoted context omitted.

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.

Argh, I misread what you wrote. It's very late here now :)

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

#162

Post by mannykannot »

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…

I think that one reason the convolutions are in the basic things was the principle that C++ should be a superset of C, which is nominally a value-semantics language, but which, with the use of pointers, very commonly (and intentionally) leads to code with aspects of reference semantics. One example of this is that C++ adopted The C practice in which arrays decay to pointers.

In addition, C++ not only inherited C's static-typing rules, but strengthened them, and complicated them with inheritance (multiple, and polymorphic or not, according to your needs), function overloads and operator overloading. Now add generic types through templates, and the cases to be handled explodes to the point where you need a Turing-complete parser.

A good case can be made for each of C++'s features individually, which leads to justifications of the form "As we want both X and Y (and without sacrificing run-time efficiency), then there really isn't any alternative to [insert counter-intuitive issue here]..."

That it works at all is a testament to the skill of the people involved. The complications that remain seem qualitatively different than the sort of gratuitous inconsistencies that you find in PHP, for example.

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

#163

Post by pjmlp »

gpderetta wrote: post #149
pjmlp wrote: post #141

Earlier quoted context omitted.

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

Try to write a GUI WIndows app, COM server, or service daemon in Rust and C#, then let me know which one is more native.

Bonus points if it is a UWP one.

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

#164

Post by viperscape »

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…

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.

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

#165

Post by masklinn »

jhasse wrote: post #157
masklinn wrote: post #61

Earlier quoted context omitted.

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

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

Bugs aside, compilers are not wrong, they may be too limited for what you're trying to do. Which is a different situation.

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

#166

Post by oblio »

tomohawk wrote: post #75
virmundi wrote: post #14

Earlier quoted context omitted.

I find Spring to be great. I grant that I've used it since 2.0, but really it does everything quickly, easily, and is well documented. Especially with Spring Boot. I'm writing a core service in Go because Java 9 broke a Maven plug-in (that I don't need now). Holy crap is it painful. I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the…

I big part of learning Go, once you've done a lot of Java is to unlearn the things that you had to do as a successful Java programmer. You're used to looking at problems through the lens imposed by the imposing bag of tools and abstractions that is Java, as well as obsolete language design decisions (I'm looking at you, inheritance). Resolve to look at things and think about things differently. I have to give credit…

This doesn't seem a Java-oriented criticism:

> I know that I'm learning, but it's hard to layer the application. Most tutorials show passing the database connection through all of the functions, or use closures that define all of your routes in such a way as to make the db visible.

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

#167

Post by pdpi »

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.

He assures us based on him being Walter Bright. That’s good enough for me.

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

#168

Post by gpderetta »

pjmlp wrote: post #163
gpderetta wrote: post #149

Earlier quoted context omitted.

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

Try to write a GUI WIndows app, COM server, or service daemon in Rust and C#, then let me know which one is more native. Bonus points if it is a UWP one.

I wouldn't want to be caught dead writing a GUI Windows app (I might do Qt if forced at gunpoint though), so I'm probably not the best person to test this :)

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

#169

Post by jhasse »

masklinn wrote: post #165
jhasse wrote: post #157

Earlier quoted context omitted.

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

> There's also the case though where the Rust compiler isn't helping you, but is just wrong. Bugs aside, compilers are not wrong, they may be too limited for what you're trying to do. Which is a different situation.

Well, most compiler bugs are cases where the compile "is wrong" and "being too limited for what I'm trying to do" also sounds like a bug. So this reads to me as "aside from when they are wrong, compilers are not wrong" ;)

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

#170

Post by gpderetta »

72deluxe wrote: post #158
gpderetta wrote: post #117

Earlier quoted context omitted.

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.

Hey, digraphs are still there, they are almost as much fun as trigraph!
Post reply on HN