C++ confessions of a C developer
Engineer Bruce Bye talks about attending this year’s Meeting C++ in Berlin and how it has somewhat changed his feelings towards the C++ language.
A confession: I went to Meeting C++ 2016 as something of a C++ sceptic.
I think my distrust of the language stems from a combination of my lack of bandwidth set aside to properly learn how to use it, and exposure to too many examples of abuse of its power. Many of those abuses were perpetrated by perfectly intelligent, well-meaning software engineers. They understood the need for maintainable code, yet still ended up at times producing fragments that seemed nearly impenetrable.
Given my admission to not having given C++ “sufficient” attention, could this lack of penetration on my part result from a lack of familiarity with the paradigms? Maybe partly; I also don’t come from a Computer Science background, so some of the highfalutin concepts that are instilled in many from their undergraduate days I have had to pick up in later years. That said, however, from casual conversations it is clear that there is some resonance in the wider coding (C++ using) community around my distaste for certain common constructs. So it feels like there must be at least some nugget of truism in my amorphous blech++.
All of which sets the scene for my arrival at Meeting C++ this year, with an overall anticipation of needing to bite my tongue quite a lot, but equal determination to keep an open mind. Let me just say at this juncture that I found it to be a very well-run convention with a great breadth of interesting talks. I’m not just sucking up here; I’m genuinely looking forward to catching up on some of the recorded talks that I was unable to attend owing to my C++-like inability to be in two places at once. (Sorry; cheap jibe; I am of course aware that C++11 gave us built in threading.)
As luck would have it, the first talk I attended was “Learning and Teaching modern C++” given by Arne Mertz. Early in the talk he quoted Douglas Crockford prompting a knowing chuckle from around the room:
When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. I suppose it was a way of showing off, and I suppose it worked because I was the guy you went to if you wanted to know how to use a particular feature….
I suspect that anyone who’s been developing for any length of time recognizes that description in someone they have worked with, and most of us probably recognize an element of it in ourselves. The trouble is that some people never seem to graduate to the next paragraph of realizing that “some of those features were more trouble than they were worth.” Even those that do still leave a trail of code full of too much trouble, which some poor sucker has to maintain. With a stroke of karmic luck, hopefully we each end up maintaining our fair share of such troublesome code, even if it’s not our own… and so the cycle continues.
This, and the ensuing talk, gave me a reassuring feeling that the core C++ community recognizes this aspect of their ecosystem, and is open to doing what they can to improve it. The thrust of Arne’s argument was around reaching out to the majority “Dark Developers” to foster the use of “Modern C++”. (For the benefit of relative outsiders like me, if you mention “Modern C++” to a room of thoroughly engaged C++ devs, then as far as I can tell they will infer “best practices of coding C++ using the most recent standards” and not just “using all the new gizmos afforded by the most recent standards”.)
During the remainder of the convention, I had other conversations and picked up gobbets from other talks, which further reinforced the warm fuzzies I was starting to get about the C++ community’s self-awareness of horror. I was well on the way towards rehabilitation as a potential C++ devotee.
At this point I’d like to give special mention to Timur Doumler’s talk on the importance of knowing your hardware. This was a fine introduction to why it remains important to understand how the hardware works when writing truly performant code, but it also highlights one of my reservations about C++ (or any higher level language) for doing this task. Sure, C++ compilers are really, really good these days, and it’s really unlikely that you can implement any existing standard C++ construct (be it list, vector, or what have you) to perform better than what’s already available, simply because of the amount of effort that’s already gone into making these the best they can be.
The issue is one of abstraction, which is also a key strength of std::. In order to use std::vector, I don’t need to understand how it is implemented. My mind is freed up to focus on doing the innovative part of my program. However, in order to design my vector-using algorithm to get the most out of my hardware, I not only have to understand how the hardware works but I need to understand how my data accesses map onto that through a layer I didn’t otherwise need to understand. That adds an extra dimension to the task of optimization, which already requires a certain mindset.
That thought served as a bit of a road bump on my Damascene conversion, but the real diversion came later, listening to some of the closing talklets. The ones that have stuck most in my mind were light-hearted fun-poking at either the language syntax, or the language specification itself. We developers enjoy considering something that must be so, and taking it to an absurdist illogical conclusion, but nobody would do that for real…right?
On the syntax side, it is necessary to precisely define the standard in order that a coder need not worry about the proprietary peculiarity of the compiler/platform for which they are writing code. It is also an unfortunate necessity that some degree of backwards compatibility be preserved. The latter results in a growing multitude of edge- and indeed corner-cases which, owing to the former, result in lengthy specifications going into the nitty gritty detail. Of course, nobody wishing to remain sane would attempt to learn a programming language using its specification, but the perception of that language’s difficulty is exacerbated by a specification measured in inches of thickness.
When it comes to absurd language syntax, things are a little greyer. Whilst nobody using the language in earnest would incorporate such arcana into their daily code, as I said we enjoy poking fun even at the things we love. The danger is in such “perfectly valid code” excerpts leaking out of that context and being used as shining examples of the language’s badness. I’m not sure whether such mis-quotations would convince anybody who wasn’t already unconvertible, but it’s additional noise that could confuse and deter someone who is undecided. In a similar way, Michael Moore was recently quoted out of context as an endorsement of Donald Trump’s US presidential campaign. “Hey, I share Michael’s liberal values, maybe Trump’s not so bad. Too bad I don’t have time to go and watch the whole film and realize he doesn’t agree with Trump at all…”
I fear C++ may have got itself into a bit of a Perl-esque quandary. Bjarne Stroustrup once wrote, “Within C++, there is a smaller and cleaner language struggling to get out.” I think that, in fact, there are a plethora of smaller languages not merely struggling to get out, but already out there, in the minds of C++ developers. Because of the breadth of C++, most developers are familiar with some subset of the language, whether because of the code examples they have encountered or the constructs they find suits them best. These dialects have varying degrees of cleanliness. Compare with Perl’s Tim Toady Bicarbonate.
There are many more things that Bjarne has said that I whole-heartedly agree with by the way. I would recommend to anybody to read his FAQ, and closely heed many of his pearls of wisdom. A closer adherence to his pragmatism might be the shining light at the end of the C++ tunnel for waverers like myself.
I went to Meeting C++ as something of a C++ sceptic. I came back from Meeting C++ with my scepticism polymorphed.