Google Reveals Its Cloud Computing Vision

Essentially this is how humans operate already. How many times a day do you have minor but insignificant misunderstandings with people? Probably quite often, especially if you are in a foreign country and yet we all get along just fine.

Turning squishy requirements into something specific enough to actually design a solution around is a pretty important step in any project.

Is that supposed to be a counter-argument?

Because, that's the parent's whole point: that the same (they can't be defined or at least defined easily) holds for those "squishy human requirements".

>What is it about information machines (as opposed to humans) that make them unable to handle ambiguity?

Obviously the fact that they only follow specific instructions at their lower level, and thus any ambiguity has to be explicitly translated to a non-ambiguous set of commands.

A fellow human does this translation automatically in their mind (and even they, not always perfectly).

>Why can't a machine handle ambiguous input? It could defer to the operator, did you mean this? did you mean that? It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty (both true and false are epistemic locations of absolute certainty).

Most of these sound recipes for disaster in any practical application...

And even that's besides the point, since all of these need to be programmed just as well as non ambiguous commands, but with more branching and special casing -- again explaining why handling ambiguity is hard.

Oh, and "randomly choose from a number of possible ways to continue" sounds like Clippy from hell...

> What is it about information machines (as opposed to humans) that make them unable to handle ambiguity?

Of course, if designed for ambiguity, information machines can handle it.

But in my experience, solving a problem with software first involves defining the problem. Most problems are "squishy", in that they are ill defined. The end user has needs and knows those needs, but hasn't thought through all the ramifications of automation.

I've started a requirements process many a time with the question: "what do you want this to do", and then diving down to specify each behavior, including critical path functionality, error conditions, alternate paths, roles in the system, performance, timeframes, and other attributes. All of these are fundamental pieces of automating information flow, but aren't typically considered by a non technical person. Hence my use of the term "squishy". (I wrote a blog post in 2003 about how software crystallizes business processes: http://www.mooreds.com/wordpress/archives/46 )

And I don't know of any software process that can handle that. Even tools designed for non developers like Excel and Zapier force users to go through edge cases.

Finally, I'm certainly no expert on some of the new AI technologies that might be game changers. (I did enjoy reading The Master Algorithm, which talks about the schools of AI and some of the achievements.)

Underspecified.

Understanding, correctly, what an underspecified system should do is a strong AI problem (in most cases, at least). All (or nearly all) unbuilt systems are underspecified (as well as many built ones). We do not yet have strong AI. Hence, we have developers who will continue to collect paychecks for the foreseeable future (your "tired meme").

> What is it about information machines (as opposed to humans) that make them unable to handle ambiguity? Why can't a machine handle ambiguous input?

Your focus on "ambiguous input" misleads you. The difficulty is more like ambiguous output.

If you pay more than 20% of the advertised rates of AWS bandwidth, you're being robbed. 10% or less is doable.

If you need durability guarantees, consider if the cost problem is storage or bandwidth. If the problem is bandwidth costs (in other words: your data set is small and accessed often), store at S3 or Backblazer or similar, and place a server or two at a cheap bandwidth host with Nginx and aggressive caching policies.

I've done this for a couple of customers who did not trust other data storage options with their data, and you can rent a server + multiple TB of transfer for a fraction of a the cost of 1TB transfer from S3....

Look into IPFS, interplanetary file system. You still need machines to serve files. However, the system has some definite advantages:

    1. A file/directory is referred to its immutable hash.
    2. A request for a specific hash is made to the network, not a single machine.
    3. All machines that have that hash can swarm-download, like bittorrent
    4. All communication is point-to-point encrypted
    5. For backend, you can mount IPFS directly to the file system, via /ipfs and /ipns

And, while I don't have as drastic an opinion as others, there are operational issues. The most recent one was mysteriously disappearing outbound emails. These are worse than they should be, because there's no real way to escalate and get someone's attention, even if you're willing to pay for it. The support model is not the same as for the newer Cloud services.

Is this right? Do you really mean 1 million nodes? Even if only 1000 nodes, who are the people using the high end of computing power, and for what?