Don’t Believe the Hype

Yet again the chaotic news from the UK has distracted me and I therefore haven’t even begun thinking about an editorial. The rolling news frequently claims, ‘Breaking news: Announcement expected soon.’ People then talk for ages filling time until ‘Something Happens’. The big bold lettering claiming there is breaking news is certainly attention grabbing. Newspapers also try to draw our eyes with cleverly worded headlines. Programming articles and talks also have an honourable history of catchy titles. ‘How I Learned To Stop Worrying and Love X’, ‘X considered harmful’, ‘What is X and why do I care?’, and the like.

Often these seem very formulaic so it should be simple to get AI to generate them. I say AI, but I jest. Picking a verb or noun at random from a list to fill in some blanks would work. The internet seems to be littered with ‘awesome’ (or other over-the-top word) headline generators. I tried one for my ACCU conference proposal and the suggestions were varied. ‘How to Use Random to Understanding’, ‘10 Steps to a Successful Random’or ‘What [Current Popular TV Show] Can Teach You About Random’. Maybe you don’t fall for cynical marketing or other such distractions, but some people do. We could dig into why conspiracy theories work, but that is outside my area of expertise. When we lived in London, we spent an amount of time talking to Dr Gordon Wright, a lecturer in Psychology and researcher at Goldsmiths, University of London, about conspiracy theories and why people take them on board. You can follow up by reading a few of his publications [Wright] if you want. This is a broad topic, and Gordon understands it far better than I do. There are many reasons conspiracies gain ground, but sometimes feeling like you have realized something few other people know becomes a feedback loop. The more people tell you that you are wrong ‘proves’ your point. An easy trap to fall into and a hard one to escape. Sometimes I convince myself I know where a bug is hiding or the root of a performance issue and would waste hours if someone doesn’t stop me. Of course, this differs from believing a conspiracy theory, because I can be persuaded around relatively quickly. Likewise, most of us can see through the hyped-up headlines. Listening to both sides, trying to find evidence, and avoiding confirmation bias all help.

Sometimes out and out lies or ‘spun’ headlines aren’t the problem. Some of us are distracted by shiny new things. For a long time, we have seen various languages touted as the successor to C++. Go was introduced by Google a while ago, with version 1.0 released in 2012. This issue has an introduction to the language if you’ve not tried it before. I recall being told Go is safer because it uses garbage collection. Many other languages do as well, and some would suggest that deterministic destruction can have its advantages. Some claim Go compiles quicker too [Golang]. It comes with inbuilt concurrency options too, having been specifically designed for networking and multiprocessing. Elements of concurrency are now part of C++ though. I couldn’t possibly say if one is better than the other. It probably depends on how you define ‘better’. Then came Rust. I am told Rust emphasizes performance, type safety, and concurrency and enforces memory safety. Many people do seem to be enjoying using it. Carbon is another language started at Google and explicitly touted as “an experimental successor to C++” [Carbon-1]. It claims to have “Safer fundamentals, and an incremental path towards a memory-safe subset.” There are various other successor languages too, including Cpp2; see Lucian’s article in this edition of Overload.

C++ was not introduced by a company. It is an ISO language, so agreement is required to introduce new features or make changes. It also tries to keep backwards compatibility, though will sometimes make breaking changes, and this includes elements inherited from C, though C is also evolving. Wikipedia notes that C++ began as an early fork of pre-standardised C [Wikipedia-1]. Bjarne Stroustrup has written about C and C++ interoperability [Stroustrup02]. This paper investigated how the future evolution of C and C++ can best serve that community. The paper is now over twenty years old, but still contains many sensible and relevant ideas. The second section is entitled ‘Red herrings’ and he nails the reasons statements “confound and inflame debates” about C and C++, but I believe these apply to more recently statements about C++ versus ShinyNewLanguage. He talks about mischaracterisations deflecting away from more salient matters. For example, “I don’t like OO so C is better than C++.” It’s very hard to decide which language is better suited for a task, and a company deciding to use Carbon, for example, will have trouble finding people with five plus years’ experience for the language. When Go first came out, I did see recruitment agents asking for several years’ experience in Go. You couldn’t make this stuff up! However, that’s a recruitment agent problem, rather than a language war issue. Finally, Bjarne also points out “Often, a language is chosen for a project based on little knowledge of the future task, mostly on a couple of programmers’ previous experience, and on what happens to be available.” Even if there were a perfect language for a task and you knew all your future requirements, if you can’t get the staff, you will either need a training budget, or have to make do with an ‘inferior’ language. And I suspect no language is perfect. Perhaps I should invent a language called Perfect, if no one has beaten me to it. We can be sure it will be Perfect in name only. Don’t believe the hype.

New rivals to C++ frequently point out the legacy that C++ needs to support. The committee does tread carefully. Releasing ABI breaking changes is infrequent. Compiler implementers have to tread carefully too. Gcc talks about the complexity of managing different version numbers and options [GNU]. They also talk about ABI checks they use, ending by saying “Perhaps there are other C++ ABI checkers. If so, please notify us. We’d like to know about them!” Any new-fangled, upstart language that isn’t ISO standardized is free to do whatever it chooses, right? Well, maybe. I had always thought of C# as a Microsoft language, leaving them free to change things at will. This may be partially true, and I have lost track of many newer features since I haven’t used the language in anger for a couple or so years. However, C# was open sourced a while ago and the common language infrastructure (CLI) is ISO and ECMA standardised [ISO]. This allows .Net code to run on non-Windows platforms. Having standards might not be a bad thing.

Trying to learn a new language can be difficult at the best of times. For a new language, we have extra challenges. The docs for Carbon say it’s “currently an experimental project. There is no working compiler or toolchain.” You can try out code on the compiler explorer [Carbon-2], and it will be interesting to watch how this plays out. Back in 2013, I wrote about learning fantasy languages [Buontempo13] and suggested a new language wouldn’t have code you could copy on Stack Overflow (SO) and there wouldn’t be any books you could buy to learn from. I can’t currently see a cpp2 or Carbon tag on SO and if I search for books, I find ones relating to Mac programming using the Carbon API, which is a different matter. Naming is one of the hardest problems in programming, and programming language names are often really rather difficult to search for on the internet. C, C++, D, r, G; sometimes slapping “lang” on the end helps, but not always.

Many people have a pot shot at C++. It is a frustrating language at times and can be difficult to learn. However, I enjoy coding in C++ and think many of the recent changes have made life better. I am very grateful to the committee members who spend time and money keeping things moving. While thinking about hype, I recalled Russel Winder giving a talk at Canary Wharf in London a long while ago, entitled something like ‘C++ is dead’. The talk wasn’t recorded, but I did find a slide deck [Winder13] from Russel’s lightning talk for the 2013 ACCU conference. His title was ‘Who needs C++ when you have D and Go?’ He walked through an example calculating the sum of the squares of numbers between 0 and 100 that are divisible by seven. The slides show various approaches in Python, D and Go. He then shows what we used to have to do in C++. His conclusion was “D is the real winner as the functions work out of the box. The Go code requires lots of extra code. Until std::range exists it (C++) is the loser.” And here we are now, with ranges. I suspect Russel would have been delighted with the introduction of ranges to C++, but then gone on to lambast C++ in other ways. Calling out problems with a language and showing other approaches often leads to incremental improvement. Causing controversy with attention grabbing titles can lead to positive outcomes.

Sometimes attention grabbing is purely gratuitous. Modal dialog boxes materializing just as I am typing being a case in point. Or my PC (personal computer) announcing an immediate reboot is required. We are often told to avoid scams by being wary of anything demanding immediate action. The sense of urgency is purported to produce a slight panic, rendering one incapable of thinking straight. I am not suggesting my PC is trying to scam me, but I do wonder sometimes. It’s possible to flag chats or emails as high importance, and I often accidentally find a key combination to do this by mistake. If I see an email marked as being of high importance, I am usually somewhat skeptical.

We are used to red flags indicating high importance or warnings. We use symbols to convey ideas. Stock phrases and headlines or titles use patterns to convey a lot of information in very few words. If we see a title ending in a question mark, we suspect Betteridge’s law of headlines applies [Wikipedia-2]. Can any headline that ends in a question mark be answered by the word ‘no’? I’m not sure how to think through the self-reference in this question. Betteridge’s law suggests the answer is ‘no’, which proves the law is wrong. This takes us rather close to a Gödel sentence and then we hit the limits of provability in formal systems. You can’t have consistency and completeness. (See [Gödel] for more details.) You can’t have your cake and eat it.

Now, some stock phrases are culture specific, so forgive me if I have failed to take this into account as I write. Furthermore, some words and phrases fall out of favour. In April 2019, I wrote a piece entitled ‘This means war!’ [Buontempo19], exploring how careless use of language can upset people. We often use foobar or similar terms borrowed from the military when we write code snippets, without realizing the background to the words. Recently people have been discussing the default branch name of ‘master’ in version control and moving to a different name. The words ‘master’ and ‘slave’ do conjure up much unpleasantness. Whenever this happens, some people will complain about PC (political correctness) gone mad, or more recently about “tofu eating wokerati” [Guardian22]. Perhaps that is somewhat culture specific too, being tied to current affairs in the UK. It’s a great phrase though. I, for one, fully embrace tofu.

We use titles, headlines and even variable names, like temp, to indicate more context. If someone says, “Hold my pint,” we expect a diatribe or long tale of woe. A friend stayed over recently and we showed him around our house. The previous owners told us many tales about the house. We were told of a plague pit at the end of the garden, a cock fighting pit under the floorboards and many similar tales. We settled into starting each with the phrase “Legend has it”, as a useful shorthand.

There is nothing wrong with a spot of controversy or hype. The trick is to pick your way through the attention grabbing silliness and make things better. I’d like to think that, in some small way, Russel contributed to C++’s ranges without realizing it. Let’s call out the things we don’t like and work on incremental improvement of whichever language we choose to code in.

References

[Buontempo13] Frances Buontempo ‘Learning Fantasy Languages’ Overload 116 August 2013, https://accu.org/journals/overload/21/116/overload116.pdf#page=3

[Buontempo19] Frances Buontempo ‘The Means War!’ Overload 150 https://accu.org/journals/overload/27/150/overload150.pdf#page=4

[Carbon-1] Carbon on github: https://github.com/carbon-language/carbon-lang

[Carbon-2] Compiler Explorer: https://carbon.compiler-explorer.com/

[GNU] ‘ABI Policy an Guidelines’ in The GNU C++ Library Manual https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

[Gödel] ‘Gödel’s Incompleteness Theorems’ (2013) in Stanford Encylopedia of Philosophy https://plato.stanford.edu/entries/goedel-incompleteness/

[Golang] Golang Vs C++: https://mindmajix.com/golang-vs-cpp

[Guardian22] ‘Suella Braverman blames ‘Guardian-reading, tofu-eating wokerati’ for disruptive protests’ at https://www.theguardian.com/politics/video/2022/oct/18/suella-braverman-blames-guardian-reading-tofu-eating-wokerati-for-disruptive-protests-video

[ISO] ‘ISO/IEC 23271:2012 Information technology – Common Language Infrastructure (CLI)’: https://www.iso.org/standard/58046.html

[Stroustrup02] Bjarne Stroustrup (2002) ‘C and C++: a Case for Compatibility’, The C/C++ Users Journal, https://www.stroustrup.com/compat_short.pdf

[Wikipedia-1] Compatibility of C and C++: https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

[Wikipedia-2] ‘Betteridge’s law of headlines’: https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines

[Winder13] Russel Winder (2013) ‘Who Needs C++ When You Have D and Go?” from a Lightening Talk at ACCU Conference 2013
https://www.slideshare.net/Russel_Winder/who-needscwhenyouhaved-andgo

[Wright] Dr Gordon Wright, Goldsmiths, University of London: biography and various articles: https://www.gold.ac.uk/psychology/staff/wright-gordon/

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD technically in Chemical Engineering, but mainly programming and learning about AI and data mining. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.