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

21–30 of 285 posts

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

#21

Post by api »

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…

C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need.

It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.

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

#22

Post by bayindirh »

lallysingh wrote: post #6
ioquatix wrote: post #4

Yes, C++ is a complex language. Yes, it has a ton of warts if you know where to look. But, you can write beautiful software with it, and it can even look beautiful too. Yes, there are alternatives, but when it comes to performance, expressiveness and actual deployability, C++ is pretty awesome.

Meh. The performance is almost never worth the huge complexity jump. Instead, profile an app in a higher level language and if any part's too slow, implement that in C/C++. That'll quite often be a low, single digit percentage of the app. Get the performance for substantially less engineering/maintenance cost.

This is not same for all cases. For example scientific and high performance computing, image processing, or other tasks which need short run times or applications where a single digit optimization results in hours of run time difference is always worth it.

Also, since C++ is native, very memory efficient data structures can be written. This property can be leveraged to write very small, very efficient and very resilient loops to be written which can run for months at a time, and since you have the absolute control over memory management, you can prevent unwanted bloating or leaks pretty easily.

Last, but not the least; CPUs weren't that powerful 10-15 years ago. My desktop computer was as fast as the first Raspberry Pi. Python, JS, even Java were very unpleasant experiences back then.

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

#23

Post by sbpayne »

flukus wrote: post #17
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 don't use go but some of your more general complaints sound like good things to me. > Regardless of which you choice, Go appears to lack the niceties of prebinding the JSON into a struct. Boilerplate. Oh, and you have to do the same to write the JSON out! The more time I spend doing maintenance the more I've learned to love this sort of boilerplate. It makes it much easier to trace where things are being used acros…

YES. 100x yes to this. I started a new job some time ago where Java / Scala were mainly used (prior C++ background).

I can logically step through flow control and figure most things out. Except the amount of "magic" for the sake of reducing boiler plate made debugging some issues really tricky.

Anytime I'm about to reduce boiler plate somehow, I try to ask myself whether it's going to introduce some type of tribal knowledge. That is, will someone without any knowledge of e.g. this codegen be able to step through and understand what's going on.

I feel that people reduce boiler plate without constraints far too often

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

#24

Post by pjmlp »

Well, most of his points regarding complexity are not C++ specific.

The thing with equals applies to most languages that allow to redefine operators.

Even Java has gotten quite complex, I bet he would have quite an hard time succeeding at one of those quiz questions certifications (SCJP and friends).

And simplicity can also turn into more complexity, manual memory management in C vs C++, "templates/generics" in Go, libraries to work around language limitations in JavaScript (npm, yeoman, gulp, grunt, webpacker all at the same time).

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

#25

Post by pjmlp »

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…

Regarding D, it looks like that, but any big code base enjoys meta-programming (mixins), templates.

They have a ton of warts regarding annotations, usually worked around by using templates, because on that case they are inferred.

The semantics of shared are still being worked on.

The way const/immuatable works, makes some devs just give up and remove them from their code.

I can equally tell some Objective-C issues.

Yes, in general they are better than C++, but not without their own warts.

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

#26

Post by zenhack »

flukus wrote: post #17
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 don't use go but some of your more general complaints sound like good things to me. > Regardless of which you choice, Go appears to lack the niceties of prebinding the JSON into a struct. Boilerplate. Oh, and you have to do the same to write the JSON out! The more time I spend doing maintenance the more I've learned to love this sort of boilerplate. It makes it much easier to trace where things are being used acros…

Also, if you really want to write code that's agnostic to whether you're working directly on the DB object or a transaction, you can just declare that interface yourself; it's not like in java where the implementing class has to opt in.

The absence of the interface being predeclared for you does mean more boilerplate, but I agree that transactional vs. not doesn't strike me as a good thing to be hiding; this particular case seems like maybe a very reasonable omission. I try to avoid abstractions that leak.

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

#27

Post by pedasmith »

bayindirh wrote: post #22
lallysingh wrote: post #6

Earlier quoted context omitted.

Meh. The performance is almost never worth the huge complexity jump. Instead, profile an app in a higher level language and if any part's too slow, implement that in C/C++. That'll quite often be a low, single digit percentage of the app. Get the performance for substantially less engineering/maintenance cost.

This is not same for all cases. For example scientific and high performance computing, image processing, or other tasks which need short run times or applications where a single digit optimization results in hours of run time difference is always worth it. Also, since C++ is native, very memory efficient data structures can be written. This property can be leveraged to write very small, very efficient and very resili…

Well, you can spend 5 months writing your software in C++, and a month fixing your bugs and doing a bit of optimization. Or you can spend 3 months writing C# or other modern language and have another 3 months to optimize, all the while enjoying substantially faster compile times and super easy refactoring.

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

#28

Post by repsilat »

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…

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

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

#29

Post by convolvatron »

api wrote: post #21
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…

C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need. It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.

just a contrary opinion. I read the c++ book in the very early 90s. someone told me it was the future of programming.

every single c++ shop I've worked at since has said, 'well, yes the language is a mess, but if you stick to a well controlled subset, its really pretty good'

and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so I guess the 'sane subset' argument is ok in theory, but really not in practice.

i've actually seen some really* clever mixin/metaprogramming with templates. it was a total disaster, and in a different environment it could be a really great approach. i could never understand it in complete detail, but if C is a 38 that you can use to blow your foot off, C++ is a 20ga shotgun with a pound of c4 strapped to your head.

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

#30

Post by WalterBright »

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…

> 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 let go of the old decisions.

(There's always some major and vocal user who has build their entire store around some ancient feature.)

For example, why does C++ still support EBCDIC?

Post reply on HN