C++: “model of the hardware” vs “model of the compiler”

	Author:	“No Bugs” Hare  Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

Recently, I have run into [P1063R0], and was literally stunned with a way those guys (mis)interpret certain fundamental aspects of C++ philosophy. By today, I found what I don’t like about their position – and am able to articulate it, so here it goes.

Disclaimer: THIS POST IS SPECIFICALLY ABOUT C++; other programming languages MAY BE (and most ARE) different in this regard.

Disclaimer #2: unfortunately, [P1063R0] is very vague about justifying some of its claims – so I had to make quite significant leaps to connect the dots. If any of the authors of [P1063R0] is ready to provide alternative justification of their wording mentioned below – I will be happy to amend this post to reflect it (however, I cannot guarantee that amended post will be any more favorable to the “model of compiler” or to P1063R0).

P1063R0 and “model of the hardware” becoming “model of the compiler”

In the very beginning [P1063R0], the logic goes as follows:

• first, they’re quoting Bjarne: “C++ is a general-purpose programming language providing a direct and efficient model of hardware combined with facilities for defining lightweight and efficient abstractions.” No problem here – in fact, I am a big fan of this concept.
• “We suggest as a friendly amendment that the quote should say “a direct and efficient model of the platform”but then, the authors of [P1063R0] suggest a “friendly amendment” to this quote: “We suggest as a friendly amendment that the quote should say “a direct and efficient model of the platform”. For example, C++ templates provide a direct and efficient map of the compiler’s code generation facilities, rather than of any hardware feature”. This is where the problem starts; actually, following their logic, original Bjarne’s quote becomes diluted, transitioning from original “model of the hardware” via conspicuously-vague (and IMO weasely) “model of the platform”, and in fact into a “model of the compiler”.
• and then, [P1063R0] implies that their approach (which is BTW a special case of lambdas) is a better “direct and efficient model of hardware” than Coroutines TS; while P1063R0 isn’t clear on why they’re better in this regard, it seems that the implication goes because their approach exposes more of compiler+library internals (“model of platform” in P1063-speak) to the end-programmer.

At this point, I don’t want to start arguing about [P1063R0]-vs-Coroutines-TS, but rather want to emphasize that

NB: I have to say that I have no idea what does Bjarne thinks about it (and sure, it would be nice to hear from him on this kind of ‘friendly amendment’ to his quote), so I cannot tell whether they’re misusing Bjarne’s quote or not; however, I am clearly entitled to agree or to disagree with (a) original quote, and (b) its modified form.

What’s So Different Between ‘Model of the Hardware’ and ‘Model of the Compiler’?

On the first glance, it might look strange that I am so picky about the difference between ‘model of the hardware’ and ‘model of the compiler’. However, there is a fundamental difference between the two, which IMNSHO MUST NOT be ignored.

Let’s take a look at the programming language (with its compiler) from a 50’000-feet point of view. What is the programming language doing for us? The answer is simple: from a 50’000-feet point of view,

That’s it – no more and no less; in other words, programming language has TWO AND ONLY TWO interfaces – one with human programmers, and another with hardware, that’s it.

“we MUST NOT care about compiler internals beyond our task definition (which is based on (a) humans, and (b) hardware, that's it). But it also means that a proper business-level definition of any programming language MAY refer to humans (who are on the one side of the translation), and MAY refer to hardware (which is on the other side) – but MUST NOT refer to anything else! It is a classical case of everything-else-being-an-implementation-detail – and we MUST NOT try to overspecify this everything-else (at least to keep implementation options open). In classical business analysis, if we have a business-level task which defines what we have to do, it is dead wrong to specify how we should do it; in [DDMoG] a few examples of improper business requirements are considered – such as “we should use TCP for our project” – and it is shown that such a (mis)specification is a Bad Thing(tm). Exactly the same applies to programming language and compiler: we MUST NOT care about compiler internals beyond our task definition (which is based on (a) humans, and (b) hardware, that’s it). 

As I understand it (and as always when trying to interpret somebody’s else intention, I can be wrong), the whole point of the original Bjarne’s quote is that C++, unlike many of the other programming languages, cares NOT ONLY about being easy-to-use by human beings, but also about being efficiently mapped into the hardware. Let’s note that those many-other-languages are still within their rights to ignore hardware while staying faithful to the proper business-level definition of their task (that is, until an interpreter/compiler becomes a de-facto standard which dictates the language – which did happen to a language or three and IMNSHO did contribute to demise of such languages).

Oh, and BTW, the argument from P1063R0 (“templates provide a direct and efficient map of the compiler’s code generation facilities, rather than of any hardware feature”) doesn’t justify introducing compiler into the picture. From my point of view, templates can (and IMNSHO SHOULD) be seen not as a “map of the compiler’s code generation facilities”, but, for example, as “a much better way to express stuff previously-expressed-with-macros”, or “a way to express generalized algorithms”, etc. etc. – all of which can be expressed in terms of source code, which in turn is already in the picture as a way for humans to express themselves. In other words – if not for human programmers having a need to simplify their lives (or to be able to express more complicated things) – templates won’t be there (and BTW, it took compiler writers about 10 years to implement templates properly); ergo, templates are there NOT because of the need “to map compiler’s code generation facilities”, but because of perfectly legitimate business needs which can be expressed in terms of valid interfaces of the programming language.

Why so Much Fuss About It?

This whole thing might look trivial – or obvious, and the next logical question is “hey, why you’re paying so much attention to this minor issue?”

“My problem with introducing a 'model of the compiler' into the picture, is that it can be used to justify pretty much anything without any relation to real-world requirements.My problem with introducing a “model of the compiler” into the picture, is that it can be used to justify pretty much anything without any relation to real-world requirements. In terms of maths, it can be used as a kind of “false implies true”, or “on an empty set pretty much any statement is true” statements – which are technically correct statements, but at the same time are perfectly useless and often utterly misleading.

And IMSNHO, this is exactly what has happened in [P1063R0]: starting from this IMNSHO-fallacy about “model of the compiler” being important, they got to an implication that overspecifying things in the programming language (which exposes more of “model of the compiler” to the end-programmer) is inherently better than underspecifying them. This, in turn, is an extremely dangerous statement – which BTW IMNSHO contradicts to another Bjarne’s writing, [P0976].

But the problem I see with introducing implementation details of the compiler into the philosophy is much more general than that – it can be used to justify pretty much anything, and IMNSHO that’s where the real danger to the language lies.

Dixi.

Don't like this post? Comment↯ below. You do?! Please share:

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.