4 ms·

Well, but C++ does take a lot of time to compile. The whole meta language implementation is relatively dumb for a lack of another word. So should every C++ prod

Well, but C++ does take a lot of time to compile. The whole meta language implementation is relatively dumb for a lack of another word. So should every C++ product now be scraped and rewritten either in rust, ocaml, or C? Or is it upon the Developer to see these problems and find a workaround?

Crinus 7y ago
The problem didn't seem to be that C++ was slow to compile but the manager' inability to understand that C++ was slow to compile (i'm ignoring the whole "architecture astronaut" and "untestable code" angle because it relies on the author's ability to judge that and from my experience people need a lot of time to become familiar with non-trivial C++ codebases and way more often than not they blame the codebase itself and whoever wrote it for that). Considering the project folded it might also have been a sign of bigger issues with management there.
- acqq 7y ago
  What you ignore is: "It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable)." I'd like here to quote this: https://blogs.msdn.microsoft.com/ricom/2007/02/08/performance-problems-survery-results/ https://blogs.msdn.microsoft.com/ricom/2007/02/08/performanc... "Which of the following is more likely the culprit of this crisis that has your boss in a panic: 1) A developer failed to code a good algorithm in some module and now a very smart person must come along and replace that module with something much better. 2) The project has far too many layers of abstraction and all that nice readable code turns out to be worthless crap that never had any hope of meeting the goals much less being worth maintaining over time." "Of 27 responses at this writing 8 didn't specify #1 or #2 at all or were balanced 4 went clearly for #1 15 went clearly for #2" I've had my own experiences of #2 on different occasions (I work for decades already).
  - Crinus 7y ago
    Yes, without having enough information to judge for themselves people tend to assume the worst. This applies to both the poll you linked and to people coming head first to a new complex codebase they have no idea about (yet need to learn fast due to boss pressure).
    - deleted 7y ago
      [deleted]
    - acqq 7y ago
      My experiences do confirm that there are developments which are indeed “worthless crap that never had any hope of meeting the goals much less being worth maintaining over time.“ There is a real problem of making unnecessary and long-term bad abstractions, and there is a lot of such often in the code using Boost, as an example.
arethuza 7y ago
I suspect projects in a new language always look better for a while as there simply hasn't been the time for cruft to build up, everyone is excited about the new language and learning how best to apply the new features. NB I'm saying that things Rust aren't 'better' than C++ - just that initially all new project in a new language have a positive bias (as do new projects) and that time will tell how big the advantage really is.
dep_b 7y ago
This article doesn't feel like an attack on C++ but rather C++ written by incompetent people.
Traster 7y ago
Large codebases can take a long time to compile, but if, as the article claimed a simple new Hello-World example is taking minutes that's because your build system is unnecessarily rebuilding everything every time.
- mbeex 7y ago
  I know not all things should be attributed to technical causes. But I'm a consultant and I often have to deal with - to me - new MLOC piles of C++ code. These code bases are of course almost always non-trivial and my first approach is most of the time - If I am permitted - to analyze the include structure and to optimize it. Removing headers, pimpl, basic things. Only then would I even begin, to explore particular problems. Side effect is an intermediate 500 feet view, that develops along the way. Many developers are too hasty, taking too narrow an approach.
- C1sc0cat 7y ago
  People need to remember that in the old days several minuets to compile was the norm and you might have to wait your turn in the queue. I recall working in my first jobs terminal room and one of the engineers came in to login to AUWE ICL - and shaking her head after seeing 38 jobs in the queue in front of hers
slavik81 7y ago
C++ is never fast to compile, but some design decisions will make it much slower than it needs to be. The less stuff you put in your headers, the faster it will build (for the most part). You can also sometimes make templates slow by programming horrors like iteration through repeated template instantiation. There's an old joke about those sorts of problems. "Doctor, it hurts when I do this," says the patient. The doctor replies, "then don't do that."
lasagnaphil 7y ago
There are many techniques to combat compile times in C++. One of the more easy solutions is to not use heavily templated header-only libraries too much, which is precisely what the architecture astronaut mentioned in the article did. Many people say that templates in C++ is a zero-cost feature, but it slows down compile times so much up to the point that you can't call it "zero-cost". I think it's just another tradeoff that C++ developers have to make - between generic code, performant code, and fast-to-compile code.

Crinus 7y ago

The problem didn't seem to be that C++ was slow to compile but the manager' inability to understand that C++ was slow to compile (i'm ignoring the whole "architecture astronaut" and "untestable code" angle because it relies on the author's ability to judge that and from my experience people need a lot of time to become familiar with non-trivial C++ codebases and way more often than not they blame the codebase itself and whoever wrote it for that). Considering the project folded it might also have been a sign of bigger issues with management there.

acqq 7y ago
What you ignore is: "It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable)." I'd like here to quote this: https://blogs.msdn.microsoft.com/ricom/2007/02/08/performance-problems-survery-results/ https://blogs.msdn.microsoft.com/ricom/2007/02/08/performanc... "Which of the following is more likely the culprit of this crisis that has your boss in a panic: 1) A developer failed to code a good algorithm in some module and now a very smart person must come along and replace that module with something much better. 2) The project has far too many layers of abstraction and all that nice readable code turns out to be worthless crap that never had any hope of meeting the goals much less being worth maintaining over time." "Of 27 responses at this writing 8 didn't specify #1 or #2 at all or were balanced 4 went clearly for #1 15 went clearly for #2" I've had my own experiences of #2 on different occasions (I work for decades already).
- Crinus 7y ago
  Yes, without having enough information to judge for themselves people tend to assume the worst. This applies to both the poll you linked and to people coming head first to a new complex codebase they have no idea about (yet need to learn fast due to boss pressure).
  - deleted 7y ago
    [deleted]
  - acqq 7y ago
    My experiences do confirm that there are developments which are indeed “worthless crap that never had any hope of meeting the goals much less being worth maintaining over time.“ There is a real problem of making unnecessary and long-term bad abstractions, and there is a lot of such often in the code using Boost, as an example.

arethuza 7y ago

I suspect projects in a new language always look better for a while as there simply hasn't been the time for cruft to build up, everyone is excited about the new language and learning how best to apply the new features. NB I'm saying that things Rust aren't 'better' than C++ - just that initially all new project in a new language have a positive bias (as do new projects) and that time will tell how big the advantage really is.

dep_b 7y ago

This article doesn't feel like an attack on C++ but rather C++ written by incompetent people.

Traster 7y ago

Large codebases can take a long time to compile, but if, as the article claimed a simple new Hello-World example is taking minutes that's because your build system is unnecessarily rebuilding everything every time.

mbeex 7y ago
I know not all things should be attributed to technical causes. But I'm a consultant and I often have to deal with - to me - new MLOC piles of C++ code. These code bases are of course almost always non-trivial and my first approach is most of the time - If I am permitted - to analyze the include structure and to optimize it. Removing headers, pimpl, basic things. Only then would I even begin, to explore particular problems. Side effect is an intermediate 500 feet view, that develops along the way. Many developers are too hasty, taking too narrow an approach.
C1sc0cat 7y ago
People need to remember that in the old days several minuets to compile was the norm and you might have to wait your turn in the queue. I recall working in my first jobs terminal room and one of the engineers came in to login to AUWE ICL - and shaking her head after seeing 38 jobs in the queue in front of hers

slavik81 7y ago

C++ is never fast to compile, but some design decisions will make it much slower than it needs to be. The less stuff you put in your headers, the faster it will build (for the most part). You can also sometimes make templates slow by programming horrors like iteration through repeated template instantiation. There's an old joke about those sorts of problems. "Doctor, it hurts when I do this," says the patient. The doctor replies, "then don't do that."

lasagnaphil 7y ago

There are many techniques to combat compile times in C++. One of the more easy solutions is to not use heavily templated header-only libraries too much, which is precisely what the architecture astronaut mentioned in the article did. Many people say that templates in C++ is a zero-cost feature, but it slows down compile times so much up to the point that you can't call it "zero-cost". I think it's just another tradeoff that C++ developers have to make - between generic code, performant code, and fast-to-compile code.