
The Time Needed to Write “Effective Modern C++” - ingve
http://scottmeyers.blogspot.com/2015/04/the-time-needed-to-write-effective.html
======
mpu
Is this guy actually writing C++ programs in the wild? He often presents
himself as an apostle in the C++ church, but, I am always surprised that he
does not seem to apply his guidelines into any practical project of his.

As a programmer, I'm suspicious when people have opinions and give advice but
never showed me more than snippets of code. Like a master tailor that wouldn't
sew. How come he gets that much recognition and respect?

I would be much more inclined into accepting advice from someone like, say,
Carmack, that has successful projects in C++ under his belt. (Many people
consider Doom 3's code beautiful C++, yet, the choices made there are very
controversial, and far from "modern".)

I also put Bjarne Stroustrup in the same category.

What do you think?

~~~
mikekchar
His webpage: [http://www.aristeia.com/](http://www.aristeia.com/) indicates
that he has been a programmer since 1972. Even if he has been doing
training/consulting for a couple of decades, that leaves a lot of time to get
the basics down. I've never met him, though I have browsed one of his books
once.

My own personal feeling is that books like these can be invaluable for people
starting out in the industry. It gives you a reference point to relate to. If
he can explain things well and people can understand his writing, then it can
be useful even if the person isn't the best living coder on earth.

At some point in your development, you need to branch out from what people are
saying in books and start to form your own opinions. You have to start
questioning what the "experts" are saying and try to experiment with other
techniques. It is frustrating when people hang on to certain ideas just
because a famous author said it. Sometimes it holds us back. It doesn't make
their contribution any less valuable, though, because at least newbies are
getting to a certain level due to the well written books.

~~~
jlarocco
I largely agree with you, BUT, this version of Effective C++ was less opinion
and style oriented and more a guide to avoiding easy to make mistakes with
some of the new C++11 and C++14 features. Not following many of the guidelines
will result in incorrect and broken code.

My recollection of the older books is that they covered "best practices," and
ignoring them may have been bad style, but the code would still be technically
correct. Quite a few are still style issues, but it's important to recognize
the difference before deciding to ignore them :-)

------
blt
I write C++ for a living and I like it, but it bothers me that we need a book
that's essentially a list of "you can easily fuck this up by accident, watch
out!"

for now, it seems that C is insufficiently expressive and everything else is
too slow. but the complexity of C++ is troubling.

~~~
angersock
Everything else _isn 't_ too slow, though, especially if you hit any
meaningful IO.

~~~
unstabilo
Or if you use clever algorithms. I don't have benchmarks at hand, but I
suspect that an FFT in Python is faster than a naive Fourier transform in C.

~~~
easytiger
Err, why?

~~~
chris_b
Because the FFT in python is almost certainly implemented in C, and probably
more cleverly done than a naive FFT that I/you/someone would whip up as part
of a C program.

~~~
easytiger
Is this a joke? Something written with the same algorithm in c will be faster
than python. Why not use someone elses non naive FFT impl in c then as well?

~~~
rprospero
I think the argument isn't that Python code out performs C code, it's that
code written by mediocre Python programmers often outperforms code written by
mediocre C programmers. C code is fast enough the mediocre programmers get
used to letting the language bail them out. Python programmers know that their
language is slow and that they have to work around it.

I've encountered this several times in my own career. A co-worker who writes
in C will be implementing a process in parallel with my Python implementation.
A week later, my O(N) Python code is outperforming my colleagues O(N^3) C
code, since I chose a more complex algorithm which is trickier to get right.
The C programmer then re-implements my method in C, which would completely
trounce my own code, except I've spent that time leaning on BLAS and LAPACK,
speeding up my operations again. The C programmer then starts using fast
libraries instead of her own code, again beating my old source, only to find
that I've now pushed a good chunk of the processing onto the GPU.

Eventually, I will run out of tricks. The final draft of the C code will
trounce the final draft of my Python code. However, during most of the
creation process, my Python usually out performs their C. Also, a truly
talented C programmer would write my colleague's final draft as her first
draft, negating every advantage that I had in the process. However, that's not
a situation that I'm likely to run into, because places hiring truly talented
programmers aren't likely to be hiring me.

~~~
easytiger
Makes literally no sense. The c developer would simply use the same c/fortran
library the python implementation is based on. You are creating a false
dichotomy for the sake of it.

~~~
rprospero
The c developer _should_ use the same c/fortran library that the python
implementation is based on. A _good_ C developer _would_ use that library. In
my experience, mediocre C developers will _not_ use that library and will
implement their own, naive version.

~~~
easytiger
This has not been my experience.

------
misiti3780
All of his books are great - especially the one on STL. Herb Sutter wrote some
great C++ books also. On a side note, based on that picture of him sitting at
this desk, he is still using iPod V1

~~~
quotemstr
Sutter's written that we should use "async" everywhere (even though
conventional threads have numerous advantages) and that we should use "auto"
everywhere (even to the point of writing "auto x = int{5}" instead of "int x =
5" and "auto foo() -> void" instead of "void foo()"). I'd take his advise with
a grain of salt.

------
curiouslurker
I wonder how long it took Kernighan and Ritchie to write 'The C Programming
Language'? Amazon says the 2nd edition (1988) is 272 pages long but looking
back, it felt like it was 80 pages :) Going by the OP's math (of the language
creator being twice as productive) prolly 4 months?

~~~
TylerE
Remember that that's inluding like 60 pages of what are basically printed man
pages.

~~~
unwind
When K&R was written, it's not a given that the man pages for C functions
already existed, is it?

~~~
Sanddancer
They were, albeit potentially more terse than is available now. System III's
functions section was pretty full by 1983 even [1].

[1] [http://minnie.tuhs.org/cgi-
bin/utree.pl?file=pdp11v/usr/man/...](http://minnie.tuhs.org/cgi-
bin/utree.pl?file=pdp11v/usr/man/u_man/man3)

~~~
dagw
_System III 's functions section was pretty full by 1983_

K&R was published in 1978

------
oskarth
This is interesting, but the hours are vastly overestimated, at least compared
to similar metrics (e.g. from the deliberate practice and expertise
literature):

 _If we figure a 40-hour work week... it wasn 't my only activity. Let's knock
that number down by 20% to account for my occasionally having to spend time on
other things._

There's no way anyone spends 40 or even 30 hours a week _writing_. Most
authors spend something like 3-4 hours a day writing - and that's a good day!

See for example the chapter on writers in Cambridge Expertise Performance
Handbook ([http://www.amazon.com/Cambridge-Expertise-Performance-
Handbo...](http://www.amazon.com/Cambridge-Expertise-Performance-Handbooks-
Psychology/dp/0521600812)).

In general this type of reasoning (40h work week => time for 40h of writing)
makes time estimates troublesome in my opinion. Another example is people who
claim to write code for 40, 60 or even 80 hours a week. A look at actual
RescueTime data gives a sober picture:
[https://news.ycombinator.com/item?id=209195](https://news.ycombinator.com/item?id=209195)

Of course, you could claim a lot of the work happens in breaks, and I would
agree. But then the actual weekly number for our most beloved artists,
programmers, and scientists is more like 24*7, literally. In that case, it
makes more sense to talk about it in on the timescale of days, weeks, months
or years.

~~~
TheOtherHobbes
I find the hours amazing. My understanding is that a typical tech publishing
cycle is three months for a first draft, with an SD of around 1.5 months, and
a page count of 300-600. Not infrequently the book will be a side project and
not the author's main gig.

E.g. When iPhone OS (as it was) first appeared, in-depth guides like Erica
Sadun's were on the shelves almost as soon as it was released.

Even if some of those authors had limited distribution beta versions, they
still worked their way through all the new features of the OS, wrote and
tested sample code, and wrote all the content in a couple of months.

I understand Meyers wants to make sure the content represents industry
practice, and that takes longer than just cranking out some code and making
sure it works.

But even so - that's still a surprisingly long time for a tech book.

------
ternaryoperator
When I track my time scrupulously, the results are significantly different
than what I thought they would be and also quite different from what, several
weeks removed, I remembered re the project.

So, when I read an article that does back of the envelope calculations on time
spent, based on rough estimates (20% on other projects, etc.), I find myself
suspicious of the computed results.

------
kenrikm
With the amount of time invested into writing the book it would be interesting
to see what type of financial return he was able to get for it. Certainly I
would hope he was able to make as much as if he were working in private
industry for the same amount of time. (though somehow I doubt this is the
case)

~~~
InclinedPlane
To within a disturbingly accurate margin of error I can tell you right now his
financial return for this book: zero dollars.

There isn't enough money in tech books for writers to rely on it as a day job.
At best it'll get you noticed and make other jobs or speaking engagements
easier to get.

~~~
ipsin
I am inclined to disbelieve you.

I could agree that tech writing in general doesn't pay well, but this is an
author who has sold over 150,000 physical copies, in addition to whatever
virtual sales (like mine) he's had. Even if his take is 10% for a $30 book,
that's still respectable income.

~~~
InclinedPlane
I had no idea where you came up with the "150,000 copies" figure but then I
ended up seeing the same thing listed on a page about "More Effective C++",
which has been in print for 2 decades. Even if he received $3-4 per copy sold
for all those books, that's over a 20 year timespan, that only works out to
$20k or so a year, although he does have other books. It's possible that Scott
Meyers might be a sufficiently popular author to be able to support himself
just on book income at a level comparable to having a decent day job, but at
best it's a very close thing and even so he would be one of the extremely rare
few who could do so.

------
mikekchar
Very interesting to reflect on the amount of time needed to write a technical
book on a programming language. If I compare that to amount of time taken to
write code (and forgive me for the horrible KLOC metric), I think one could
easily average about 300 lines of good C++ code (including tests) per day on a
new project -- probably more if you are working alone, but let's keep it
conservative. So about 37.5 lines per hour * 1350 hours = ~50KLOC. Say half of
it is tests, so that's a medium sized app.

I don't know why, but writing a book seems waaay more effort than churning out
~25 KLOC of tested C++. I guess it is what you are used to...

* 300 lines per day is what I averaged over a multi-year period when I was a C++ programmer. But that was more than a decade ago, so I'm guessing it would take less lines of code with "Effective Modern C++" ;-) (and yes, I measured it for interest sake...)

~~~
munificent
> I don't know why, but writing a book seems waaay more effort than churning
> out ~25 KLOC of tested C++.

It is. I wrote a programming book, and the code for each chapter was always a
breeze compared to writing the prose.

I rationalize it by thinking of English as a programming language. It has a
fantastically complex syntax and semantics, tons of undefined behavior, and a
few billion interpreters out there, each with a large number of quirks and
bugs.

Writing a program in English that does the more or less correct thing on all
of those interpreters ain't easy.

~~~
greggman
I'm actually finding it hard because I feel like I need to re-write all the
old chapters each time I write a new one.

The problem is as I go from A to B to C when I get to D I realize I really
want the code to be in a different shape. But to do that I either need to make
a C' where I take a timeout to explain why I'm refactoring the code before I
move on to D. Or, I need to go re-write A, B, and C so they fit directly into
D.

Making C` sucks because it's irrelevant to whatever the topic is. But re-
writing is also a ton of work.

You could argue I should start at Z and work backward but I'm writing as I go
so I don't know what Z is yet.

------
istvan__
Could somebody redpill me on why something like D
([http://dlang.org/](http://dlang.org/)) is not a better alternative to C++.
Is that the library support or what exactly makes C++ still a better option in
2015? I am not sure what is the best alternative to C++.

~~~
vitaut
When you develop something you consider not only the features of the language
itself, but also the availability of libraries in this particular language.
There is a large amount of high-quality C++ libraries and C++ can consume C
libraries seamlessly. In most other languages you need to write often unsafe
bindings to connect to C.

D simply doesn't have enough libraries to make it a viable choice except maybe
for some niche area. For example, there are only 6k D repos on GitHub
([https://github.com/search?utf8=%E2%9C%93&q=language%3AD&type...](https://github.com/search?utf8=%E2%9C%93&q=language%3AD&type=Repositories&ref=searchresults))
compared with 340k C++ repos. Also any high-performance code (at least in the
area I'm working) is written in C++ or, sometimes, in C.

~~~
istvan__
Thanks for the answer this is exactly what I was looking for. It seems that
C++ is in a sweet spot and it is going to be hard to challenge its position.

------
blaenk
I actually finished this book today. It's a great resource on the various
pitfalls and good practices that are present in C++11/C++14, and they are
presented in a very readable format that really lends itself to referencing
later on. I highly recommend it.

------
bankim
I've read couple of Effective C++ series books by him and I've found Effective
STL to be the most useful book for my day-to-day C++ programming at work.

------
shmerl
It's a must have book.

------
greg7mdp
Love the book!

