You got the oft-excluded part of the quote right -- temporary security -- but the actual quote is, "he who would trade Essential Liberty for some Temporary Security, deserves neither Liberty or Security."
Many people omit the word, "temporary". The suspicious part of me says they do it so their (mis-quoted) statement appears more bold and uncompromising.
Open an English dictionary (the Oxford one if you're serious), and come back. Note my fault if tbl didn't know how to speak English corectly backed then.
Surely whether or not the RFC's authors know how to spell a word has no bearing on how sensible it is to correct the spelling of "HTTP_REFERER"? I mean, if dools had said "HTTP referer" then you might have had a point, but "HTTP_REFERER" unambiguously refers to the name of the header field.
Why not a Russian? For example the Russian Mathematics Olympiad is considered harder than the International Math Olympiad by many of the top contestants.
All control flow is a subset of continuations. The stack is a continuation (calling a function is call-with-current-continuation, return is just calling the "current continuation"), loops are continuations (with the non-local control flow, like break/last/redo/etc.), exceptions are continuations (like functions, but returning to the frame with the error handler), etc. Continuations are the general solution to things that are normally treated as different. So continuations are just as efficient (or inefficient) as calling functions or throwing exceptions.
In a web app context, though, it's kind of silly to keep a stack around to handler something like clicking a link that returns the contents of database row foo. People do this, call it continuations, and then run into problems. The problem is not continuations, the problem is that you are treating HTTP as a session, not as a series of request/responses. (The opposite of this style is REST.)
In theory yes, in practice you need to reify the stack (even for one-shot continuations). Clinger, Hartheimer and Ost have a really good survey paper of the different ways to do that:
You clearly don't understand the problem. Even mod_pagespeed or memcached would be more appropriate here: They are rate-limited by the LISP kernel anyway (we are talking about dynamic content here).
Varnish sits in front of the backend, responding to all requests that it has cached content for directly, without bothering the backend at all. It lives higher in the stack than than pagespeed or memcache, and not limited by the backend's speed in any way.
