Live data from Hacker News

Why I don't spend time with Modern C++ anymore

linkedin.com

21–30 of 264 posts

Re: Why I don't spend time with Modern C++ anymore

#21
post #14

Earlier quoted context omitted.

Yes. If each file makes sense in isolation then the whole will as well. Just splitting code into lots of files won't necessarily produce files that you can figure out in 1 minute though (you have to define the boundaries between files such that they make sense).

In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing. Implementing complex functionality is going to b…

> In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing.

I've worked on a number of very large codebases and that simply isn't my experience. If code is easy to understand it tends to make good use of the domain language and therefore also be easy to search.

> Implementing complex functionality is going to be a nightmare

The opposite, in my experience. The only maintainable way to implement complex functionality is to break it into small pieces.

> everything is going to be merged in a single translation unit anyway.

That's the compiler's business. I don't care one way or the other about its implementation details.

Re: Why I don't spend time with Modern C++ anymore

#22
post #14
post #7

> If you cannot figure out in one minute what a C++ file is doing, assume the code is incorrect. This statement at first resonated with me, and then I thought about it: this doesn't reduce the complexity of the overall application or service, it just means that one file is simple. You could have 10,000 files instead of 1 much shorter one; is that any more simple?

Yes. If each file makes sense in isolation then the whole will as well. Just splitting code into lots of files won't necessarily produce files that you can figure out in 1 minute though (you have to define the boundaries between files such that they make sense).

I disagree. A complicated function may be made of a bunch of statements where each statement makes sense easily. The entire function may still be complicated. The same argument can be extended for files and projects. Even if each file is simple, if the code in those files interact with each other in a complicated manner, the project becomes complicated. This can happen despite having neat boundaries between files. Nothing stops a new programmer from writing new simple files that interact with the existing files in a complicated manner. Simplicity of source code in individual files or functions is just one of the factors behind a simple project. Simplicity of design has to go hand in hand with it.

On the other hand, a couple of files may be very complicated but the entire project could still be simple if those complicated files hide the complexity behind neatly exposed functions, and the remainder of the project does not make use of those functions in a complicated manner.

Re: Why I don't spend time with Modern C++ anymore

#23
post #2

This sounds like it's written from the point of view of implementing something inhouse. I fail to see how FPGA programming will be relevant if one wants to distribute software for consumers (or am I technologically clueless...).

Sounds like he is suffering from bias of the problem domain he is working on right now.

Which, to be fair, is also an apt description of defenders of C and C++ (I consider myself in that category). We are all susceptible to the biases of niches we have worked in and what we have seen working well in those niches.

C and C++ can be made to shine in some ways that I get the strong impression many people who happen to not have the same experiences will never appreciate, and perhaps that's not even a bad thing, maybe that just is.

Re: Why I don't spend time with Modern C++ anymore

#24
Ok. Try a different language :)?

A single language needed to solve all problems is a fallacy.

I don't see FPGA programming ousting c++, but expect higher level languages with strong parallel semantics to gain "market share". You can always call a dedicated process written in optimized c for the hottest components. Compose the rest in go, elixir, or any high level language (lisp).

Architectures will naturally gravitate to higher level languages that support cleaner composition. The tools and interfaces will push towards higher abstraction without impacting build or run time. Maybe this process is related to Kevin Kelly's inevitable. I'm an optimist here.

Re: Why I don't spend time with Modern C++ anymore

#25
I recently had to switch a project to -std=c++11 because a header I include now uses C++11 files. This change alone made compilation at least twice if not three times as slow. The new safety and convenience features are nice but compile times seem to be out of focus and getting slower and slower every year. I don't know how I feel with g++ 6.1 defaulting to -std=gnu++14.

Re: Why I don't spend time with Modern C++ anymore

#26

It just sounds like someone who couldn't handle C++ whining and making a bunch of blanket statements without really having any proper understanding. I agree that some of the features such as lambdas can use to hard to track bugs (lifetime issues) and difficult to follow code when abused. When used nicely though they can lead to simple, elegant and straightforward code (anyone who tried to use the STL algorithms befor…

Bottom line, if your code base is a mess don't blame the tool. Blame the programmers.

The problem is the attitude towards these new features that naturally leads to programmers abusing them, building overabstracted complex bloated behemoths to accomplish the simplest of tasks.

I'd say the vast majority of programmers, for some reason, seem to have an appetite for complexity --- they tend to feel that overly complicating things somehow makes their code better, especially if they can use some new shiny fancy features in the process. I don't think like that so I don't know exactly why that is the case, but perhaps it has to do with the feeling of accomplishment from having written something "big", solving simple problems with complex solutions. Instead, I'm the opposite --- I like solving complex problems with simple solutions, which means code that is usually very straightforward and only occasionally makes use of some more advanced features of the language, when it helps simplify the solution.

Re: Why I don't spend time with Modern C++ anymore

#27
post #6

There are two separate rants here that aren't delineated well. 1) C++ is too complicated, and therefore hard to reason about and slow to compile. We're going to argue about this forever, but you'll have to agree that the spec is very large and warty compared to other languages, and that C++ tends to take far longer to compile (this was already a problem a decade ago, it's not specific to "modern" C++). 2) The future…

Can't really argue about 1. About 2, in-order single instruction execution hasn't been an assumption for a very long time; c and c++ optimizers (and programmers) have been able to take advantage of these CPU features for a while. There are language extensions (Cilk++, OpenMP), to take advantage of extra cores for fine grained parallelism. Regarding GPUs, arguably C and C++ have the most mature and transparent offload…

Parallelism: yes, although OpenMP isn't nearly as accessible as e.g. Swift async closures. C++ only got proper language-native threading in C++11.

for large scale programming the only sane model is a flat, cache coherent one

Do google view their datacenters as a single flat cache-coherent memory space? No, they built mapreduce instead. That's the point of view I'm coming from: distributed systems engineering working downwards. Rather than a single large program operating on a single memory space, a set of fragments whose programmers are aware that there is latency when communicating between nodes. DRAM is just another "node" that you have to send messages to and wait for a response.

Re: Why I don't spend time with Modern C++ anymore

#28

Wonder if they tried IncrediBuild to reduce their compile time? They are right that C++ - while faster than ever before - takes much longer to compile than many other languages.

Things like Incredibuild can only help so much. You still need to have a decent project structure, and enough computers to effectively cut down compile time.

Though (as mentioned in another comment) if your project is a big ball of inter dependencies then the link time will dominate.

I've seen compile times with Incredibuild that are less than a minute, but the link takes 5-10 minutes. Or better yet crashes due to the pdb size.

Re: Why I don't spend time with Modern C++ anymore

#29
post #4
post #2

This sounds like it's written from the point of view of implementing something inhouse. I fail to see how FPGA programming will be relevant if one wants to distribute software for consumers (or am I technologically clueless...).

According to the writer's LinkedIn profile, he comes from the world of High Frequency Trading. That's an area where performance is so important, that it might make sense to design your own hardware. And you certainly don't want to distribute it to anyone... I do agree with the writer that with each release, C++ has become more and more complicated, seriously hurting the maintainability of C++ code.

So it seems like he wants people to learn FPGA based programming languages (Verilog, VHDL) because he will need to hire (more of?) these people soon.
Post reply on HN