> I've think I've heard it's a standard assumption to claim a rate-limiting process will eventually "get 99.9% of the way where it's supposed to go in a finite amount of time, and so 'that's good enough.'" Engineers are the ones who make this claim about real-world parameters; I've never really heard any other discipline talk in this way. Is this a joke which is commonly taught in engineering school? For what situations?

It's a joke about the differences between scientists and engineers more than about any real world truth. By nature, engineers tend to be interested in science only insofar as it permits them to do something -- build some cool gadget, or whatever. The stereotypical engineer wouldn't care about science at all, except that, hey, using it, we can make computers and vandegraff generators and build bridges and stuff.

Scientists are more interested in science for its own sake, rather than its applications. Consequently, they are far more likely to be interested in distinguishing between a function that approaches some value asymptotically and one that actually meets or crosses that value. To an engineer -- unless it has bearing on how something is built or made, who cares?

The variation of the joke I hear is that a male mathematician, scientist, and engineer are on one side of a room, and there is a beautiful woman on the other. The rules are that they can only cross the room by travelling half its width at a time. The mathematician and the scientist quickly calculate that they'll never make it ALL the way to the woman, so they don't bother trying. The engineer gleefully starts heading for her, because he'll get close enough for all practical purposes.

I noticed, while in school, that, like any other major with "science" in the name, "computer science" is not really a science major. It's an engineering major that leans on the science side. Pure science would bore a great many computer scientists, but the traditional engineering disciplines are sometimes too lax about theory for them. A good computer scientist tends to be focused on getting something to work and getting it to work efficiently -- with concessions along the way to the programming principles of extensibility, modularity of data, code readability, and so forth -- but will often enjoy things like algorithm analysis and language parsing theory for its own sake.