shaper_pmp

You might want to clarify you never retained any PII, unless you can 100% confirm that that favicon request didn't include any embedded user- or installation-id in cookies, headers or the like?

It was only a minor issue that got resolved quickly thanks to your question, but DDG's response to this whole issue of losing users' trust seems to be accurately characterised by the phrase "a succession of embarrassing own goals". :-/

Wow - they nicked my entire comment from reddit days after I posted it there, and didn't even give credit. :-(

http://www.reddit.com/r/Android/comments/138res/google_launc...

I'm not sure I buy the augmented reality angle - the hype-generating marketing adverts seem to imply it, but nobody who's playing it has mentioned anything about AR - just a GPS- and map-based game. Augmented reality is when you use things like the phone position and orientation to overlay graphics onto a camera-view of the real world, like this: https://www.youtube.com/watch?v=U2jSzmvm_WA&feature=play...

As such I doubt it has much to do with Google Glass specifically - more likely I suspect they're tracking people walking around as they play to build a massively improved pedestrian-route database for a new pedestrian (and in-building, for places like malls, museums, etc) version of Google Maps: http://www.reddit.com/r/Android/comments/138res/google_launc...

Shaper_pmp, but thanks for the mention. ;-)

This is true - doing is undoubtedly the best way to learn.

What I meant was that you shouldn't do something for money, or to be put into production before you know what you're doing. ;)

What you really mean here is that humans are complex and adaptable and have a theory of mind, whereas computers aren't and don't.

This, however, is not a fault. I work in web development, and I see every single day confusion and problems caused by a mismatch between what someone asked for and what someone else understood they wanted.

When you're writing computer code you should specify exactly what you want - architects don't design a house by drawing four walls and a roof and some rough, to-the-nearest-metre dimensions on the back of an envelope, because then houses would fall down and kill people.

We shouldn't design software this way for the same reasons.

The main problem is that people are lazy, and think in generalities. That's fine for socialising, but many things in life require precision (especially in our increasingly-complex society)... and lazy people used to relying on implication and inference find it a great effort to be as precise as is required.

The solution is not for programming languages to guess what people want based off their imperfect, imprecise and un-thought-through requests - it's for people to learn to request what they actually want, instead of asking computers to essentially "do some stuff with a thing".

It's not a question of success of communication - it's a question of imprecise requirements, lossy communication methods and inescapable rules of information theory.

Hi there - article author here. ;)

> I don't like idea that you should keep inconvenience in place to keep of idiots. Idiots won't succeed anyway but inconveniences harm professionals and novices.

I think you've misunderstood - the argument is not to keep inconvenience in, it's to avoid taking things out which aren't actually a problem in practice.

As you rightly said, "human languages are geared towards interactive communication not towards describing problems and solutions precisely". Therefore any attempt to turn a programming language into English is not going to address the real difficulties of programming - specifying the problem and solution in enough detail, modelling the desired system in your head, avoiding/considering/handling edge-cases, etc.

All it's going to do is to make the experience of programming fractionally easier for people with effectively zero programming skills, and hence give them unwarranted self-confidence.

It's like making a bike easier to ride by gluing the rider to the seat - sure it's technically "harder to fall off", but the problem isn't usually the rider falling off the seat - it's the whole bike falling over, taking the rider with it.

Likewise, the hard part of programming isn't remembering precise and finicky syntax - it's making sure your own thinking is precise and finicky enough that you can accurately express it in such a finicky, precise language.

I'm not arguing in favour of long function names (I'm not entirely sure how you got that from my post) - I'm arguing against people who think that by changing "print('Hi there');" to "print 'Hi there'" they've somehow solved the problem of "programming being hard to do".