The Law of Leaky Abstractions

Joel Spolsky has a nice essay on the leaky abstractions which underlie all high-level programming. Good reading, even for non-programmers.

timeout

[czaby]

There is no magic. TCP is reliable even using IP because there are timeouts. If your data cannot be transmitted for a certain time limit, you will get timeout wich is perfectly legal result.

Re:Informative

[Jamey12345]

Com and it's decendants are supposed to take care of this. In reality they work relativly well, but also lead to larger and larger libraries. The simple reason is because Com has to remain backwards compatable, by way of leaving in the old functions and methods.

Really?

[CowboyMeal]

Here's the magic part: TCP is built on top of IP. In other words, TCP is obliged to somehow send data reliably using only an unreliable tool.

Seems to have worked pretty well so far...

Re:timeout

[Minna Kirai]

"Reliable" means "always works", it doesn't mean "always obeys the spec". (Unless you use a circular definition)

A timeout is a legal result by the TCP specification, but it's not reliable, because your data didn't make it through.

By the IP specification, your data might not make it either- and that's a legal result because the spec allows it to drop packets for any reason at all. That doesn't mean IP is reliable, just that it obeys its own definition.

Of course, no real protocol can ever meet this restrictive definition of reliable. Some maniac can always cut through your wires or incinerate your CPUs. Calling TCP a "reliable protocol" is just a shorthand for "as much more reliable than the underlying protocols as we could manage"

The timeout you mention does make TCP more reliable than IP, because it alerts you to the data loss, where the application can possibly take steps to retransmit it sometime in the future.
But its not as if TCP could ever achieve the perfect reliablity that the simplest, most abstract description of it would imply. Which is why, as the author says, those who rely on the abstractions can get bitten later.

Re:Great examples

[Anonymous Coward]

Just a note, some people who use Dreamweaver do actually understand HTML. For example, I use Dreamweaver, and I can state that one of my favorite bugbears is people building page layouts using tables, when they should be using divs, with CSS for the positioning.

Re:Informative

[GlassHeart]

C++ is not a seperate language from C, it is merely an incremental improvement

C++ is first of all definitely a separate language, in the sense that a C++ compiler will fail to compile legal C code. (Many compilers accept both C and C++ code, but must necessarily process them as either C or C++, not both.) If C and C++ are not "separate languages", then converting code from C to C++ or C++ to C must be a trivial task.

C++ is also a separate language in the sense that good C++ code (the definition of which does seem to differ depending on which edition of Stroustrup you look at) looks little like good C code. The STL (and templates in general) and exceptions result in source code that looks little like C.

it is merely an incremental improvement, an add-on basically. That's why it's called C++ and not D.

Stroustrup wrote: "I picked C++ because it was short, had nice interpretations, and wasn't of the form ``adjective C.'' in his own FAQ [att.com]. No mention of emphasis on C++ "merely" being an "incremental improvement".

If you're curious, yes, there was a B, but there was not actually an A (or rather, there was, but it was called ALGOL).

B came from BCPL [bell-labs.com].

Re:Informative

[GlassHeart]

Every assembly instruction directly maps to a machine code instruction, so there is absolutely nothing hidden or being done behind the scenes.

Nonsense. On the 80x86, for example, a one-pass assembler cannot know if a forward JMP (jump) instruction is a "near jump" (8 bit offset) or a "far jump" (16 bit offset). It must generate code to assume the worst, so it tentatively creates a "far jump" and makes a note of this, because it doesn't know where it must jump to yet. In the backpatching phase, it may now know that the jump was actually "near", so it changes the instruction to a "near jump", fills in the 8-bit offset, and overwrites the spare 8 bits with a NOP (no operation) instead of shifting every single instruction below it up by one byte.

A multi-pass assembler can avoid the NOP, but the fact is still that the same JMP assembly instruction can map to two distinct machine language sequences. The two different kinds of JMP are abstracted and hidden from the programmer.

Typically, assemblers also provide:

• Symbolic constants
• Symbolic addresses
• Macro definition and expansion
• Numeric operators and conversion on constants
• Strings

which are all useful abstractions.

Re:Informative

[GlassHeart]

Also, could you give an example of some valid C that isn't valid C++? I have yet to encounter any.

The most commonly-encountered difference is probably:

#include <stdio.h>
...
char *p = malloc(100);

which is perfectly valid (and good) C. It is invalid C++ because the void * return type of malloc() must be explicitly cast to (char *). However:

#include <stdio.h>
...
char *p = (char *) malloc(100);

would actually be substandard C. Since C assumes that an unprototyped function returns int, forgetting to include stdio.h would generate an error, which is silenced by the explicit cast.

Furthermore, the most recent iteration of ANSI C, known as C99, contains many features not supported in C++.

Re:Informative

[pabs]

Also, could you give an example of some valid C that isn't valid C++? I have yet to encounter any.

how = about //* this, for */ example;

Re:Non-leaky abstractions

[Anonymous Coward]

Common Lisp has rational bignums (no rounding errors, no matter how much precision is required--until you run out of memory). Floats are only used to approximate irrationals or to trade accuracy for speed.