▲ 171 points
back
149 comments
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?
His past C++ projects (or lack thereof) do not tell much about the quality of his books. He teaches people how to master C++, and that's a very precise skill. He doesn't claim to teach how to organize software, or how to manage collaboration between people, or any of the other skills that are necessary for a successful software project.
It's the same way that good grammar is only one of the skills involved in writing a great novel. Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example.
> Some scholars really grok grammar, and are excellent at teaching it, yet they haven't written great novels. I'm thinking of William Strunk Jr (of "The Elements of Style" fame), for example.
Not sure that Strunk, or the successor Strunk and White, are good examples here; they didn't "really grok grammar", in fact, they were pretty bad at both understanding it and teaching it, and their advice consists of a lot of incorrect information and vague platitudes. E. B. White was actually a good writer, but much of his writing violates the prescriptions in The Elements of Style.
Geoff Pullum has a good rant on the subject, if you want more detail: https://chronicle.com/article/50-Years-of-Stupid-Grammar/254...
So, this is exactly why it's an interesting question to test if the suggestions in the "Effective C++" series are actually good suggestions, or are just someone expounding rules that sound good in theory but don't actually help in practice.
I think some of the most solid and forward thinking advice I've seen and used in my C++ have come from his books.
As for Carmack:
I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.
He gave a talk at DConf 2014. He said "I'm gonna make a confesion which will make many of you instantly stop listening to me which is I don't develop software." Meyers is a teacher, a very good one. http://www.ustream.tv/recorded/47947981
The best coaches are not necessarily the best players.
Like in sport, coaches are good at pointing to particular aspects of someone's game, but were not necessarily great at putting it all together on the field. You find there's different coaches for attacking, defending, etc.
They all tend to have tried playing at some level, however. Even Mourinho was a senior player for a short while.
I suspect programming gurus are no different. They may get very good at shouting RAII or SFINAE at you, without being great at executing it in a large project.
Anecdotal, but a friend of a friend talked with Meyers, and Meyers said he has not worked on any large scale C++ programs in a while.
That being said, I have worked on large scale C++ projects, with a lot of people smarter than me, and the biggest criticism of Meyers' books and advice would be "necessary but not sufficient". I can't, off the top of my head, think of anything he recommends that would have been controversial amongst my peers.
His webpage: 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.
Are you putting Stroutrup in the I'm suspicious of his advice category or the He teaches from experience category?
While Carmack obviously is a great programmer, the fact that C++ compiler eats his `C with classes` code doesn't make him the best C++ programmer out there :)
>Is this guy actually writing C++ programs in the wild?
Well, I read one of his articles which you can find here: http://www.artima.com/cppsource/top_cpp_books.html
In it, he writes about his role with C++:
"I’ll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. Furthermore, I’ve never even tried to write production software in C++, so not only am I not a real C++ developer, I’m not even a wannabe. Counterbalancing this slightly is the fact that I did write research software in C++ during my graduate school years (1985-1993), but even that was small (a few thousand lines) single-developer to-be-thrown-away-quickly stuff. And since striking out as a consultant over a dozen years ago, my C++ programming has been limited to toy “let’s see how this works” (or, sometimes, “let’s see how many compilers this breaks”) programs, typically programs that fit in a single file. (make? Who needs stinkin’ make?) My living is based on C++, but it’s not by virtue of the programs I write in it.
It’s not by virtue of any intimate association with the language’s standardization, either, because I’ve never been a member of the C++ standardization committee, I’ve never been on the committee’s mailing lists, and I’ve never attended any standardization meetings. My knowledge of the inner workings of the committee—including the things that have had a significant impact on it—is based on what I’ve read and heard from others. This means that I may be ignorant of important forces that shaped C++ as we know it, because those forces may have been felt only within the committee.
Given that I don’t really use C++, nor do I help specify it, you might wonder what I do do. Fundamentally, I study C++ and its application. I gather as much information as I can about the language and its use (from books, magazines, newsgroups, email and face-to-face conversations with developers and members of the standardization committee, experiments with toy programs I write, etc.), organize and analyze what I find, then I package my findings in concentrated form (e.g., books, magazine articles, technical presentations, etc.) for consumption for people like you—people who do use the language. Your job is to employ C++ as a tool to write useful software. My job is to discover and package the information you need to best apply that tool.
I like to think of myself as an outside observer, not too deeply steeped in the day-to-day travails of programmers and not too keenly focused on the minutiae of standardization, yet familiar with both. This series of articles, then, summarizes what this self-proclaimed outside observer thinks have been the most important contributions to C++ since its inception...."
Great programmers don't typically write books. They are busy writing programs. 'de Raadt on C' would be a good book, wouldn't it? But he'll never have time to write it.
His books are well-researched, that is for sure. However, you cannot use his ideas as gospel. He will try to teach the most conservative way of using C++, not the best for your purposes. I particularly think that there are several areas of C++, such as exceptions and constness that should better be avoided if possible. But each one has a different way to use the language.
Those who can't do, teach.
Those who cannot do or teach, write books.
( And use the fame derived from them to get consulting gigs. )
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.
> but the complexity of C++ is troubling.
It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected.
I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it.
1) There are many other alternatives than C++ that will cover a lot of use-cases. You don't always "need" to use C++, unless you have precise needs all the time, or don't want to have another language interact with your code.
2) You can still use C++ and avoid complex features, or just use C.
3) The language keeps evolving, and I think it's great that companies are working towards an ISO standard. Few languages have that. Maybe the language will be a little easier to use in the future.
The price for zero-cost abstractions and expressiveness is a monstrous complexity. If you want clean, expressive and easy-to-write code, you have a ton of languages where you can do just that. If you want performance and expressiveness, you will have to do with C++'s complexity.
Everything else isn't too slow, though, especially if you hit any meaningful IO.
"the complexity of C++ is troubling"
This comes out of the fact that C++ is being developed more as an engineering tool than as a programming toy. When you're into real engineering, you don't have free lunch.
couldn't D, go, nim or rust fill that need?
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
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.
> he is still using iPod V1
Are you sure? I see some color contrast between the center button and the wheel, and no ring of buttons around it.
It's not V1 - that one took a Firewire cable, not USB.
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?
Remember that that's inluding like 60 pages of what are basically printed man pages.
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...).
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
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.
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.
I think that the lesson here is that it is kind of silly to try and put a time estimate on these things. How do you define time spent "writing"? Does it include time spent researching? Time spent thinking of the structure? If you pause to formulate the next sentence or line of code, should you stop the clock? Maybe we should only measure time taken in each individual key press.
It makes much more sense, and is less ambiguous, to talk about "time to complete a project". Like a book, for example.
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.
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)
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.
Being an author of a well regarded programming book has plenty of benefits that don't involve book royalties. You're considered an industry expert and can make money on speaking and consulting gigs.
John Resig may be a bigger name, and he didn't make much from publishing.
http://ejohn.org/blog/programming-book-profits/
It doesn't seem like the reward is primarily financial, though I'm incredibly glad of both Scott's C++ books, and Resig's Javascript books.
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...)
> 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.
300 lines of code per day ? Really, the LOC -measurement is highly dependent on what kind of project you are working on, and really doesn't tell much about what is going on with the project.
Don't know what the good metric is. Maybe functionality instead of lines of codes or kilobytes in the final binary. But how to measure functionality ?
300 lines per day sustained? that seems really high to me. what were you working on? didn't you ever spend days optimizing or refactoring with <= 0 net lines added?
Could somebody redpill me on why something like D (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++.
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...) 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.
D is a better alternative for many people. Speaking of Scott Meyers, C++, and D, his talk at DConf 2014 was humorous and you'll get a better sense of him.
https://www.youtube.com/watch?v=48kP_Ssg2eY
It depends on your actual goals. Personally, though I prefer Go for everything when possible, my favorite alternative to C++ is C++. If you want a true alternative, Rust is probably a smarter investment of time compared to D, based on traction. However, I'm uninformed about the D community as of late, and certainly won't be surprised of a future surge.
I am familiar with C++ and not familiar with D, but I have heard from people that D is not very practical without a garbage collector, so I suspect that D is not a good choice if you want to have memory allocation/deallocation in your own hands.
I loved D the last time I looked at it, but got tired of writing bindings / FFI code for all the libs I needed. Same thing with Lisp.
I don't want to use your arbitrarily opinionated bindings, and I don't want to have to write my own just to get started.
The language itself is amazing. I'm a fan.
But try to find a MySQL library with support for DECIMAL. Something I think should be in the standard library nowadays.
No workable solution found.
Things like that are the things that kill the language.
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.
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.
It's a must have book.
Love the book!