5 ms·

This sounds similar to an argument you could make for writing all of your code in assembly instead of C (or other higher-level languages.) Yes, there's a layer

This sounds similar to an argument you could make for writing all of your code in assembly instead of C (or other higher-level languages.) Yes, there's a layer of obscurity between a program written in C and the resulting assembly: a tool (yes, a tool, spouting abstraction all over the place!) called a compiler. As a core tenet of engineering, we create tools that often leverage abstraction in order to let us tackle more complex problems without wrapping our heads around (or writing code to handle) the details. It's a matter of balance, and we can all choose our own camps along the abstraction <=> ease-of-understanding-every-detail continuum (I'd tend to plop myself toward the former.) Just as we can create a reliable C => assembly compiler, we can create reliable tools to let us leverage abstraction for the better and focus on the bigger picture rather than the smaller.

scott_s 13y ago
I find your analogy curious, because I think it's backwards. If we're going to use C and assembly, the author is arguing for C: easier for humans to read, but we'll have to translate (compile) it so that the machine can read it. Assembly is easier for machines to read (well, not really), but harder for humans to read. My "not really" bit is because the better analogy would be C to machine code. The author's point is that HTTP/1.1 is a text-based protocol. It's inefficient that we have to translate that text into meaningful bits on either end, but it makes it easier for humans to inspect. HTTP/2.0 allows for binary communication, removing the need to translate text, but making it harder for humans to read. It's removing layers of abstraction, not adding them. The introduction is quite clear on this point: The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the HTTP/1.1 message format is optimized for implementation simplicity and accessibility, not application performance. As such it has several characteristics that have a negative overall effect on application performance. I'm not necessarily saying I agree with the author; I don't know enough about the tradeoffs in this domain to say if the loss of abstraction is worth it. But I do think it's worth understanding his arguments on its merits.
- zackbrown 13y ago
  I think we're addressing different points in the article, especially in that 'readability' and 'complexity' are distinct. Also, I think the author does make valid points, which is why I qualified that we can all choose our preferred places on that continuum of abstraction. My point is that it is sometimes (or from my perspective, often) worth it to deal with more complex (as in higher-level) technologies via tools that allow us to de-abstract those technologies than to focus on using only technologies for which we can understand every detail of their implementation. Trying to understand assembly written by a human vs assembly spat out by a compiler (with its optimizations, etc.) is a very different beast, but thanks to the tools of higher-level programming languages and compilers we rarely need to fiddle around with machine-generated assembly. Similarly, with reliable tools, we would not need to fiddle around with raw HTTP 2.0 workings, and thus rarely would the concern of immediate human-readability be an issue.
bcoates 13y ago
There's a broadly-held idea that passing around compiled images ready to be copied into memory as software is too fragile, arcane and low-level and that we should just put the human-readable source on the target machine to be consumed by the runtime. Isn't that directly equivalent to having a preference for a textual wire protocol?
- lstamour 13y ago
  I'm not sure the two relate. Textual is still made of bits, just more of them. As a stream, they can be checked via TCP for completeness and order, iirc. The danger, I suppose, is that they might be interpreted incorrectly, but that's why you've a versioned spec. Like SSL and HTTP itself, negotiate based on what the browser says it supports and the server prefers, and that's that. Binaries for software or "golden master" images for the OS are fragile not because they're binary, but because they aren't versioned as easily and they can deviate from the golden master. While on the web, a new golden master of your app/doc is a refresh away and there is such version negotiation.

scott_s 13y ago

I find your analogy curious, because I think it's backwards. If we're going to use C and assembly, the author is arguing for C: easier for humans to read, but we'll have to translate (compile) it so that the machine can read it. Assembly is easier for machines to read (well, not really), but harder for humans to read. My "not really" bit is because the better analogy would be C to machine code. The author's point is that HTTP/1.1 is a text-based protocol. It's inefficient that we have to translate that text into meaningful bits on either end, but it makes it easier for humans to inspect. HTTP/2.0 allows for binary communication, removing the need to translate text, but making it harder for humans to read. It's removing layers of abstraction, not adding them. The introduction is quite clear on this point: The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the HTTP/1.1 message format is optimized for implementation simplicity and accessibility, not application performance. As such it has several characteristics that have a negative overall effect on application performance. I'm not necessarily saying I agree with the author; I don't know enough about the tradeoffs in this domain to say if the loss of abstraction is worth it. But I do think it's worth understanding his arguments on its merits.

zackbrown 13y ago
I think we're addressing different points in the article, especially in that 'readability' and 'complexity' are distinct. Also, I think the author does make valid points, which is why I qualified that we can all choose our preferred places on that continuum of abstraction. My point is that it is sometimes (or from my perspective, often) worth it to deal with more complex (as in higher-level) technologies via tools that allow us to de-abstract those technologies than to focus on using only technologies for which we can understand every detail of their implementation. Trying to understand assembly written by a human vs assembly spat out by a compiler (with its optimizations, etc.) is a very different beast, but thanks to the tools of higher-level programming languages and compilers we rarely need to fiddle around with machine-generated assembly. Similarly, with reliable tools, we would not need to fiddle around with raw HTTP 2.0 workings, and thus rarely would the concern of immediate human-readability be an issue.

bcoates 13y ago

There's a broadly-held idea that passing around compiled images ready to be copied into memory as software is too fragile, arcane and low-level and that we should just put the human-readable source on the target machine to be consumed by the runtime. Isn't that directly equivalent to having a preference for a textual wire protocol?

lstamour 13y ago
I'm not sure the two relate. Textual is still made of bits, just more of them. As a stream, they can be checked via TCP for completeness and order, iirc. The danger, I suppose, is that they might be interpreted incorrectly, but that's why you've a versioned spec. Like SSL and HTTP itself, negotiate based on what the browser says it supports and the server prefers, and that's that. Binaries for software or "golden master" images for the OS are fragile not because they're binary, but because they aren't versioned as easily and they can deviate from the golden master. While on the web, a new golden master of your app/doc is a refresh away and there is such version negotiation.