Live data from Hacker News

C++ and the Culture of Complexity (2013)

blog.greaterthanzero.com

121–130 of 285 posts

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

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

Backward compatibility with C semantics and tooling was fundamental for C++ success. We wouldn't be having this discussion otherwise as nobody would have used C++.

Tools are great for minor upgrades of APIs and syntax, but key to C++ was compiling with existing system headers (no, realistically you do not want to maintain your own 'fixed' version), and most importantly OS and library ABI.

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

#122
post #83
post #74

Earlier quoted context omitted.

Sure they are, just not on the classical C++/Java style hence the footnote, as I was already expecting that kind of comments. There isn't "The ONE true OOP way", just like there isn't "The ONE true FP way" or "The ONE true LP way". Each paradigm has a set of concepts of what they might mean, and many languages cherry pick from there. Rust and Go implement polymorphism via traits and interfaces respectively. Rust and…

On that topic, Joe Armstrong famously said that Erlang (Erlang!) might be the only "real" OOP language out there: after all, you can have encapsulation, polymorphism, delegation, and so on, by just designing appropriate exchanges of messages between processes.

I suggested many many years ago that Erlang was an OO language and of course the community ripped me to pieces for it :) I was very pleased to see him eventually come out on my side.

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

#123
post #43
post #20

Earlier quoted context omitted.

Oh boy, you must be really young. No parallel in C++?!!!?? That is where EJBs and Spring come from. The enterprise architects that created those kind of designs, were the same ones that on earlier decade were doing them with C++. Apparently micro-services are now a thing, well on the late 90's we had Sun RPC, CORBA, DCOM. All tied together with a cluster distributed transaction management. Sprinkled with code generat…

We should all be thankful that the Java and C# communities have offered a welcoming home to all the architecture astronauts :)

In the C++ community, that OO centric coding style is called the Java style, which is completely unfair, as it really originated in C++; it was just wholeheartedly embraced (and made more usable mostly thanks to GC) by Java.

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

#124

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…

> 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 favorite opening. I see plenty of this in distributed storage, too. "It's so simple, I'd do it myself, but it's not worth my time, you go do what I said." The C++ designers seem hung up on an abstract model of machines and compilers that's a poor match for any real machine or compiler ever, and the actual compiler writers have to bridge the gap. Thank you for your efforts, which are Herculean in an Augean-stables kind of way.

[1] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

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

#125

C++ is not more complex that its competitors like Haskell or Rust.

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 the issue isn't cultural, it's inherent to the problem domain.

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

#126
>Rvalue references provide move semantics, and they solve the perfect forwarding problem. 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 don't get this. The performance issue move semantics solve doesn't exist if you just use automatic garbage collection? Is this what the article is saying?

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

#127

C++ is not more complex that its competitors like Haskell or Rust.

There are different dimensions of "complex":

1. How cumbersome a language is to use (as a beginner, as a confident developer, etc).

- C++ is rather easy to start, but takes ages to master and surprises even powerful users daily.

- Rust is hard to start, it states complexity of systems upfront in a tightly packed knot that should be handled all at once, but once you're past that, it's rather consistent.

- Haskell is very hard to start with, it is basically unlearning every imperative habit, but again, after that it's a powerful and mostly consistent tool (not without its warts, but drastically less than C++). There is some tolerance of complexity in the ecosystem, but it is clearly encapsulated in libraries and justified by papers and research interests.

2. How complex is the abstract core of a language.

- Haskell has had an amazingly simple, elegant and consistent core for decades; on the other hand, modern Haskell has accumulated a lot of research-y stuff (which is still optional to use), which may be nice/cumbersome depending on the situation. Run-time behavior feels woefully underspecified though, and can be flaky and hard to reason about.

- the mental model of Rust is bigger and more complex than in Haskell (traits, generics, lifetimes/onwership, the underlying C-like memory model), but it's definitely practical (if somewhat spartan) and consistent.

- C++ does not have a coherent vision at all: it is a pile of organically grown features with interesting (and sometimes useful) interactions. This pile is outright impossible to reason about formally.

The only definition in which "C++ is not more complex" is the definition of being easy to use for a beginner in the language.

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

#128
post #93

Earlier quoted context omitted.

I think that's spot on. I coded quite a lot of C++ in the early 2000s. Now I'm considering to jump onboard again. C++11 and successors are almost a different language. More importantly, for my niche I don't see anything that can readily replace C++. Rust has very little support for scientific computing. Julia is great, and will replace my high level statistical inference code, but it's not designed to let me design l…

If you are doing scientific computing, have you considered Fortran? The gfortran (GCC Fortran) compiler supports Fortran 2003, which has object-oriented features, and since Fortran 90 the language has had array operations and syntax similar to Matlab or Python with numpy.

I'm not a big fan of Fortran for my particular domain, which includes lots of strings (biological sequences). Here Fortran is not as quick. See for example the k-nucleotide benchmark:

https://benchmarksgame.alioth.debian.org/u64q/performance.ph...

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

#129
post #89

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…

All your complaints about C are valid, except I'd say defined but stupid behavior buried somewhere in a gargantuan language spec is effectively the same as undefined behavior.

The difference is, C lets you control how much baggage you carry along and C++ doesn't. If I want a higher-level abstraction in C, I can usually implement it pretty well using inlines and macros, void and function pointers. Will it be pretty? Hell no. Will it have all of the syntactic sugar that the C++ version does? Nope. But it will work and be usable and most importantly the complexity/risk that it carries along will be exactly what I asked for (because I know how to manage it). Using a feature in C++ means carrying along all of the baggage from its dependencies and interactions with every other feature.

If programming languages were cars, it's like the dealer saying I can't add one option to the base model. No, I have to buy the top-of-the-line model with dozens of features I don't actually care about and will never use, costing far more and oh by the way that model has door handles that will cut you. That's about when I go to the Python dealership down the street, or just stick with good old C.

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

#130
post #18

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…

> C++ is designed by its standards committee...

When it comes to design, C++ is a good example of why having a benevolent dictator is better than a committee. I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.

Post reply on HN