Knives and sticks are less dangerous: it's far easier to run away

Which not everyone can do. My fiancee has spina bifida; she couldn't walk until fairly late childhood, and running isn't ever going to happen -- it was having her aunt's pearl-handled pistol in a big granny-purse that saved her from being mugged as a child. (Mugger presents knife and asks for her wallet; she reaches into purse, pulls out the gun, cocks it, says "no"; would-be mugger wets pants and runs off. Granted, a smarter mugger would have done a cut-and-run on the purse as a whole).

Mind you, her family was from the country a generation before her; they started firearms safety training early (wild animals with rabies were a real problem in their area -- even having a few cases of dogs in their kennel getting infected).

Like almost everyone else I know, she agrees that many firearms should be restricted -- large-magazine weapons and the like -- and that safety training is essential... but taking the only effective means of self-defense away from people unable to run is unreasonable.

To start if off -- we had a report of pyramid_debugtoolbar failing with a UnicodeDecodeError this morning (on Python 2, where platform.platform() returns a non-7-bit-clean bytestring rather than a Unicode string, causing code to blow up later in the templating layer; on Python 3, it works perfectly).

Or you get a phone with Qi support, and you don't need a working USB port to charge, even with a non-removable battery. More than one way to skin a cat.

In the real world, purely functional code doesn't happen.

Sorry -- I can't buy that quite as-written. Complete projects composed only of purely functional code don't happen, sure. Purely functional code certainly does happen -- if you're doing a good job of isolating your state to small chunks of code, and building the rest of your codebase to be easy to cache, easy to memoize, easy to test, easy to parallelize and optimizer-friendly, it happens quite a lot.

But if you're writing purely functional code, you can't have any output, because that would be a 'side effect'.

The side effects in the scenario I proposed are in the printer, or the nrepl code that speaks to the socket you're connected over. Those side effects are, thus, not in the actual code under test, allowing that code to be safely run against the production system in question.

There's functional programming for purists, and there's functional programming for people who want to get things done. In the latter case -- a set I belong to -- it's all about isolation and management of side effects, not about attempting to avoid them altogether.

I suspect you haven't seen a Common LISP debugging environment. Yes, they allow breakpoints, as well as live code modification. (And if you were lucky enough to have a LISP machine, you could dive into the code behind your libraries, your operating system, etc. -- updating state on the fly, all the way back to tweaking a driver on a running machine... on the fly, in LISP).

What we have these days (say, Clojure's nrepl) isn't as powerful as that, but it's pretty damned powerful even so. Want to tie into your production system and see what a new version of a function would do against currently live production data, without actually changing the production system's behavior? If you're writing purely functional code, you can do that trivially... and the language strongly encourages pure functional code (as opposed to many "modern" languages where trying to write things to be side-effect-free is working against the grain).

If the best example you can think of is QBasic, you have no idea what a REPL can do.

Once we're on the right-hand side of the Laffer curve, you'll have room to talk. Until then, you're just being (knowingly?) disingenuous. Every serious study puts us to the left -- often, far to the left -- of the peak.

Spamhaus must be costing somebody (or some people) a LOT of money to draw such a massive attack.

They're using DNS amplification -- so that money is mostly being paid by folks running misconfigured DNS servers.

You don't want to drive to pick up groceries. OK, so how do you get them home? Horse? Somebody else drives? You just don't, because you eat out all the time?

Bicycle (folder, so it comes in the store with me -- no need to lock up outside). Or at least, that was how I picked up groceries for my urban household before moving to a block away from a market; now, I just walk next door.

Bigger picture, though: If you're looking at infrastructure investment and maintenance, high-density living (with mixed-use zoning) is far more cost-effective on a per-person basis. Maintaining utilities (and especially roads) has a huge cost per mile; put more people in less space, and put their entertainment, livelihoods and necessities near them (with transit to cover the cases that walking and biking don't reach), and you're waaay ahead in a city -- able to provide better services to more people at a lower cost.

It lives on only as a cached process, not as a live one. Those are reaped whenever anything else would use the resources they're using -- it's not _truly_ stopped, but it's a functional equivalent for all reasons that matter (unless it's your intent that your application lose all its state -- this can be useful if you're trying to clear a bug, for instance, but will have no effect on performance on the rest of the phone).

....and of which none of the competitors do as good of a job as VMware. I guess you get what you pay for.

I wish you did -- then VMware ESX's SCSI emulation would actually be up to par with what's in qemu/kvm. Sure, they implement the mandatory mode pages, but you want anything unusual? Good luck.

See well-reputed 3rd-party reference.

There's nothing out there that's so vitally important, yet incredibly rare on Earth, that makes it worth it.

If you think "rare on earth" is in any way part of the point, you aren't paying any attention. People proposing mining asteroids aren't proposing returning the materials they mine to Earth.

To amend my prior answer with an actual reference -- see http://www.phrases.org.uk/meanings/beg-the-question.html

On the subject of the reliability of said source:

While no reference work is able to claim its content is 100% definitive, every effort has been made to include here only information that is verifiable as correct. The content is researched to published book standards. The sources used in the research are twofold, either primary sources or trusted references. The primary sources include newspaper cuttings, books, films, photographic archives etc. The trusted reference sources are those that themselves derive from primary sources and have sufficient reputation to be considered reliable. These include, The Oxford English Dictionary, Second Edition, The Historial Dictionary of American Slang, First Edition, The Oxford Dictionary of Quotations, 5th Edition, Partridge's A Dictionary of Slang, 8th Edition. In addition to these are numerous reference works and databases which, although not in themselves definitive, provide a rich source of stimulation; for example, Cotgrave's A Dictionarie of the French and English Tongues, Hotten's Slang Dictionary and many others.

"Beg" is just (in the context of questions) an old-fashioned word for 'ask'.

"Beg the question" is shorthand for "beggar the question" -- to make it worthless by depriving it of its value (as, in this context, it is provided with an answer ready-made).