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

171–180 of 285 posts

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

#171

Post by loup-vaillant »

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.

Being too limited for the intended purpose is still being wrong on some level. Not a bug, but still.

Granted, sometimes you don't care: stuff like `true?1:"foo"` is of type int an has value 1, but the compiler will rejected because of a type mismatch in the conditional—but you don't care because the code smell is too big and obvious to ignore.

Sometimes however you do care, if only a little: the value restriction in ML for instance prevent some function from being polymorphic because some side effect might break the type system. This forces you to eta-expand the function definition (no partial application, you need to write the arguments explicitly), which is a bit of a hassle in some cases.

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

#172

Post by kbenson »

pdpi wrote: post #167
blub wrote: post #148

Earlier quoted context omitted.

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.

Walter Bright's response is the parent of the comment in question. This one seems aimed towards the top level commentor's response, which advanced from the pained venting in the first comment (which I understand and can sympathize with) to a much more assertive tone.

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

#173

Post by zach43 »

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…

One fairly common example of a bad C++ design edge case is the “Most Vexing Parse” problem [0].

I frequently find myself constructing objects using the () syntax will produce parse errors as the compiler is expecting a function declaration. Then replacing the () with {} just fixes it. It’s really frustrating that bad design like this is just maintained as a stumbling block for new users, instead of being fixed.

[0] https://en.wikipedia.org/wiki/Most_vexing_parse

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

#174

Post by srcmap »

pjmlp wrote: post #80
cageface wrote: post #76

Earlier quoted context omitted.

C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it. Personally I'm hoping Rust displaces it from…

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.

I used C++ for embedded CPU 68332 (25 MHz CPU) with 4MB of SRAM in ~1996 for DNA sequencer machine.

~100 + classes, single inheritance, 1,2, 3 Axis motor controls, CCD Camera, Laser, serial com channel, scripting engines, etc.

No template, no virtual functions. Worked very well at that time.

The compiler setup at that time is AT&T cfront generate C from C++ code ran in Mac and embedded C cross compiler generated the target code.

The classes are shared within company for different machines (biotech robots) to maximize code reuse.

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

#175

Post by zach43 »

stinos wrote: post #60
repsilat wrote: post #28

Earlier quoted context omitted.

Disclaimer: I don't program in C++ day to day, so maybe my experience is atypical. Moves and rvalue references (and whatever a PR-value is) and even RVO scare me. They make me want to pass pointers around, because at least I know for sure what'll happen then. (And, funnily enough, C++ seems worse than dynamic languages for this -- more magic around function calls and returns than C or Python or JavaScript.)

scare me ... because at least I know for sure what'll happen then. Which is just because once you learned how pointers behave. Similarly, if you'd just take the time to learn the basics of rvalues, moving, RVO, ..., you won't be scared by them anymore. Might thake longer than pointers, sure, but it's worth it.

Maybe this is just my experience, but it took me far longer to understand the subtleties of move semantics, rvalues, and RVO than to understand pointers and references in C++. And this is not even getting into “universal references” (which I don’t have a comfortable understanding of either)

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

#176

Post by jcelerier »

the_af wrote: post #153
otabdeveloper1 wrote: post #125

Earlier quoted context omitted.

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

> C++'s and Haskell's typing systems don't look very similar, or even of similar complexity.

yet they are. The difference between the Haskell type system and the C++ type system is that generic constraints on types are explicitely specified with typeclasses in Haskell, while they are implicitely specified with templates in C++ (though this changes in C++20 with concepts).

To make a "conceptual leap" beyond the C++ and Haskell type systems, you have to use a language with dependent types such as Idris or Coq (and actually, dependent types can be simulated in C++ ! http://pfultz2.com/blog/2015/01/24/dependent-typing/ but like all simulations, it will be slower than if it was implemented directly by the compiler).

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

#177

Post by pdpi »

kbenson wrote: post #172
pdpi wrote: post #167

Earlier quoted context omitted.

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

Walter Bright's response is the parent of the comment in question. This one seems aimed towards the top level commentor's response, which advanced from the pained venting in the first comment (which I understand and can sympathize with) to a much more assertive tone.

From context, the comment I was responding to seemed attached to the wrong parent and seemed aimed at Walter's comment instead.

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

#178

Post by humanrebar »

oselhn wrote: post #89
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…

I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this: * lack of namespaces - all names with long prefix look the same to me * just text based macros * no generics * error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking * no polymorphism * ton of un…

> no polymorphism

C has plenty of polymorphism. The compiler just doesn't do it for you. In fact, C++ started out as C-with-classes since it was a pain to keep recreating the OOP-in-C boilerplate over and over. Besides, there are more kinds of polymorphism than virtual methods. You can be polymorphic with an array of function pointers.

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

#179

Post by pegasuscollins »

edflsafoiewq wrote: post #160
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.

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

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

As a user of both rust and and C++, I certainly wouldn't consider the the lack of default constructors in rust to be a good thing. Especially for std types like Vec it is really annoying to have to initialize it explicitly.

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

That is a bad argument if you're comparing to a language that doesnt have a spec. Maybe a complete, exhaustive rust spec would be much longer than the C++ standard?

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

#180

Post by beached_whale »

I think it depends on where you sit on the stack. A library can take a lot of the complexity away from the higher levels in C++ code. The user code can look fluent and understandable. On the implementation side of the library being used(depending on where it sits in abstraction) is where some ugly complexity shows. But this also generally reflects the competence of the authors.
Post reply on HN