a third of 2013's police-reported car accidents were the rear-end crashes and a "large number" of the drivers either didn't apply the brakes at all (what?!)
That is because they didn't hit send yet. They were still staring at their phone and not concerned whatsoever with the innocents in the car with them, or the innocents in the car in front of them.
Another poster said that texters have worse response time than drunks. That is probably not true, because drunks at least have a response time. You can't respond to something when all of your sensory input is focused on something else. For texters, the response comes after the crash.
I have noticed a trend for years that rear end collisions have been getting more prevalent and the damage more severe. It was like people weren't even hitting the brakes. I blamed it on texting while driving. Now the statistics are saying the same thing.
However, I am NOT in favor of the new devices to apply the brakes when the driver doesn't. Automation in the cockpit will only lead to stupid people becoming MORE complacent in the car and will increase their irresponsible behaviors. Instead of looking up every other character to see what is going on, they will just stare continuously at their phone until they have finished their message.
Perhaps I could see having such a braking system if, after a single auto-braking incident, the car disabled itself except for low speed travel so it could pull over to the shoulder, and then, travel over 10 mph was disabled until the car was reset by a qualified driving instructor.
I would ask them if they take a check.
Not just ANY check, an out-of-state, two party, postdated, temporary, third party check. Made out for $2,000 over the disputed amount. For your trouble, please keep $1,000 of it and send the rest back in the form of a cashier's check or money order.
- No security issues (other than bad Javascript or the web server itself): there's nothing to hack, and if someone were to hack the web server itself, restoring the site is as easy as re-uploading the files (all of which can be maintained in version control like git).
For something like Jekyll, this also applies to the input. I use it for a couple of sites and, in both cases, the sources are Markdown files (easy to edit with your favourite text editor) stored in a git repo. When I'm working on updates, I run 'jekyll serve' locally and get a copy of the site on the loopback. When I want to push them, I can do jekyll build and then rsync the results to the web server (or do something more clever if I'm less lazy and want atomic updates). The entire change history of the site is stored in revision control and the revision control system contains everything necessary to recreate the site at any point in its history.
I've yet to see a CMS that allows trivial rollback to earlier versions of the site or which makes it easy to store the content in such a way that a compromised web server can't damage it.
I'm not sure I agree with your first premise. There are fairly trivial combinators that you can write in lambda calculus that are conditional flow control (i.e. reduce to either the left or right lambda expression based on a value). The implementation of ifTrue in Smalltalk (loosely) follows this model.
More mundanely, the statement is obviously false because a language constructed with the basic arithmetic operators and unconditional branches is also turing complete.
Only if the unconditional branch is a computed branch. Otherwise how would you implement a program that either terminates or does not terminate based on user input? The example that comes to mind is the x86 MOV instruction which, with a single unconditional backwards branch is Turing complete, but this relies on several other aspects of the surroundings that allow you to implement a conditional branch (or, at least, a select, which is morally equivalent).
The simplest Turing-complete instruction set is a subtract-and-branch-if-not-negative instruction, but this is a conditional branch.
I agree that conditional flow control is slightly too broad a requirement, as it depends on an imperative model. Conditional execution depending on input data might be a better way of phrasing it.
"There is such a fine line between genius and stupidity." - David St. Hubbins, "Spinal Tap"