most mobile phones, from free up through the $300 models with WinCE on them, have just plain horrid UIs. the iPhone came along and, far from being perfect or even close to it, didn't totally suck. and people were amazed, and wanted to know why their phone didn't not suck.
Windoze suck! Amiga rulez!
So you think they suck, and the Iphone doesn't - that's an assertion of an opinion, can you tell us why, with evidence or examples?
As an example: my phone's UI doesn't suck. Good things about it are that it can copy and paste, and if I want to run applications from a unofficial site, or use it as a modem ("tethering"), it doesn't need to be hacked (it Just Works). All good interfaces have objective reasons why they are good - I would be curious for some examples?
Er, I don't think the issue is about assigning "fault" or "blame", because it means we get a bad mark or something. It's about how messed up we're going to be due to climate change, and what if anything we can do about it.
Now can Man be flexible enough to survive it? That is the better question.
So for your proof I would stay away from the age old 9 out to 10 scientist agree mantra, as it is not a formal way of proving anything.
You mean the bit where he said: "But you've made an even more fundamental mistake. Science isn't democratic-- it's about evidence", and then presented a load of evidence?
in the UK we now even have police adverts pretty much telling people to denounce their neighbors
There's one of these on the billboard next to my house. I was amused to see someone has put printed stickers over the police logo reading "BOLLOCKS", and another one such that it reads "Confidential BOLLOCKS Hotline".
I'm not sure if this is just random vandalism, or part of some campaign. (The stickers keep changing positions every few days, too.)
And the 10 years "bollocks" is not bollocks - it's based on the freakin' Quake engine, which was created 13 years ago. Sure, bump-mapping and dynamic lighting is great, but hardly on-par with the shed-loads of further advances that are present in closed-source games.
You are conflating two issues. Yes, I'm sure that this game isn't comparable to what's possible in 2009 commercial engine, but these extra features are way beyond what Quake offered 13 years ago. More accurate might be to say under 5 years ago (taking Doom 3 as a rough benchmark). If you want to bitch that the game is 5 years old comparable to commercial engines, go right ahead, but please don't make false claims about it being 13 years old (the fact that it was originally based on a 13 year old engine is irrelevant. There are modern commercial engines that were originally based on the Quake engine, or you might as well whine that Linux is based on code that is 18 years old...)
By your reasoning, if we can handwave these extra features away, this would make Doom 3 no more advanced than Quake 1!
(I'm not sure why this is pitched as an open vs closed debate anyway. The problem isn't being open, it's being non-commercial. Yes, if you spend millions of dollars and have a team of programmers working full time for 2 years or more, you'll get better results than what people can achieve in their spare time. That's hardly surprising in any case, and especially makes a difference when graphics technology moves so fast. But I do think it is nice that the improvements trickle down - so what we thought of as cutting edge, that required millions of dollars just a few years ago, is now available in open source engines for free.)
Well in that case it's TFS and TFA that are misleading - do not take this as representative of open source. E.g., check out http://www.ogre3d.org/gallery/ for some decent screenshots from an open source engine.
The technology is also more comparable to Doom 3 than Quake 2 (it's just that the screenshots on TFA mostly don't seem to show them very well - even the screenshots from version 1 4 years ago showed realtime shadows for example, but for some reason these are disabled in most of the screenshots on the latest article!)
Although it was originally Quake 1 they started with, it looks like they've made major changes to it, adding in newer technology (e.g., dynamic lighting and realistic shadows, which is more comparable to Doom 3 than Quake 1).
I must admit, I was a bit confused. A lot of the screenshots in TFA look rather crappy, no different to the Quake 1 or 2, and don't seem to show off what the engine's really capable of. There's no evidence of anything newer such as dynamic shadows (the lighting on the walls could easily be precomputed lightmaps).
But go to the older article one year ago, and there are much better graphics - e.g., here you have realtime shadows, and what looks like bloom effect, and possibly bump mapping on the walls. There is one screenshot in the latest article that shows realtime shadows from a character, but it's rather hard to see in the screenshot. It seems odd why they released this latest batch in order to show its "impressive graphics".
There is also a lot more in the way of open source graphics engines - e.g., projects like OGRE (check out the Gallery).
Nonsense. This is like saying a militant atheist is a "Christian", because someone splashed water on their head as a baby, they had christian parents, and were forced to go to "christian" school.
If we define one's religion not by that person's belief or identity, but by someone else's actions and definitions, then we get into all sorts of nonsensical situations. Consider, if I decide that me shaking your hand whilst I'm dressed up as a pirate makes you a member of the Church of the FSM, and that you're "not really permitted to leave", does that make it true?
There is no such thing as a muslim child, just as we would not talk about a Marxist or Keynesian child.
Although I note that whilst usually religious organisations promote these definitions in order to inflate their numbers and force religion onto children, I suspect you're instead taking advantage of anti-Islam viewpoints, in order to make Obama look bad. But I don't really care about the politics here, just your nonsensical non-consensual definition of labelling. Who cares if he is a muslim anyway? Christian or muslim, or Church of Intel, just so long as he keeps his religion out of politics, unlike a certain recent President...
But I'm not talking about two people working on the same area - yes, the man month is mythical, but that means in the sense of having two people working on the same issue. In large projects such as where I work, we have people working in very different areas, and communication directly between these people is not required (of course, we do communicate as when necessary, but clearly, the "pair" will still need to communicate to other pairs of programmers too, so there is no difference here).
Basically, if you have enough money that you can double the number of employees, I'll agree that pair programming is worth trying. But the idea that most programmers in a development team result "in no increase in the amount of work performed" is ludicrous - if that's true, then you've got more serious problems that need resolving, that have nothing to do with not pair programming. (Given the book you quote, I suspect you're misquoting - as I say, the mythical man month is to do with adding extra programmers to a problem, and not companies that simply have more than one employee. By your reasoning, a company with 1,000 employees is mostly useless, and only slightly more productive than one with a handful of employees!)
Indeed, if that was really true, why not extend the concept? I mean, if we have 10 developers split into pairs, surely by your logic, the 4th and 5th pairs don't really do very much. So perhaps we should all group them up - just have ten people sitting round a desk, working on the same bit of code. That'll be much more productive right? It must be true, because of the Mythical Man Month!
The idea enables teams that are twice as large
Most companies don't have the resources to suddenly double their development size. I think you're making the assumption that most places are already overstaffed by a factor of 2, and hence people are already doubled up in the same bits of code, where they don't really help. Yes, there the Mythical Man Month applies, and pair programming would be worth trying, as I say.
But there are plenty of companies that aren't like that. My experience is that places are more likely to be understaffed, and need as many new developers as possible. At these places, pair programming is the last thing you want.
What few people realize though is that pair programming is boring for the person without the keyboard. It's mind-numbingly boring. It's like watching someone do mathematics homework for a whole day. I enjoy programming, but watching other people code is a lot less fun.
Yes, exactly. Even if somehow pair programming really was more than 100% of an improvement, thus making it worthwhile, from an employee point of view, it would be far less an attractive job. This isn't about being a good or bad programmer, it's just that my preferred job choice was that of "programmer", not "sit and watch someone else code".
finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently
Am I missing something? Given that most non-trivial companies can parallelise their workload for at least two people, I would expect two independent programmers to be 100% faster than a single programmer.
So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code
It's not about "volume of code", it's about functionality.
And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on
All this can be done without pair programming too. The reason it usually doesn't happen in most companies is because they don't have the resources to hire twice as many people, so pair programming isn't an option there anyway. If companies could hire twice as many people, then even with non-pair programming, you could still double people up in each area of functionality, thus spreading the knowledge base.
Pair programming only compares well to places with half as many developers, or a straw man version of non-pair programming where everyone works in a sealed box and never communicates with anyone else.
I entirely agree. Of course, a second perspective is good, but you can obviously get that without resorting to pair programming, simply by discussing with over developers. Moreover, pair programming has the problem that you both have been looking from it with the same perspective, having gone over the same route, and making the same mistakes. The idea that pair programming is a different perspective is rather ludicrous, when you've both been working together constantly - I'd argue getting a different fresh perspective, for someone who isn't biased by having done and seen everything that you've done, is better.
I think there are also other issues. Working together having to explain every thought you have to the person looking over your shoulder does make things more stressful for a programmer. No doubt the AC will respond with "OMG that makes you a crap programmer!", but this is an important thing to take into account. Whilst I am quite capable of communicating with other developers, one of the reasons I like programming is that I prefer working a reasonable amount of time on my own. I imagine this is true of many programmers, and indeed, other professions such as authors. Not to mention other issues, such as losing a great deal of flexibility now having to go around with the other person (e.g., having to take lunch break at exactly the same time, sharing desk and computer). It's one extreme to the other - a job traditionally focused on individual work, going to one that requires far more constant social interaction than most other jobs. If programmers don't like that, they'll be more likely to look elsewhere, and that's something companies have to take into account too.
So you can't catch bugs when working outside of pair programming? Sounds like a communication problem where you don't discuss the functionality with other developers, or not critically thinking about the problem from another perspective.
If a programmer can't deal with pair programming them they're a very poor programmer.
Where did he say he couldn't deal with it?
I might as well claim "If a programmer can't deal with programming on his own, they're a very poor programmer".
Is that fair? Of course not. The debate here is about which is better, and I see no evidence that pair programming is better than two programmers working normally.
The fact that advocates of pair programming can't argue their case, other than resorting to ad hominems of "You must be a crap programmer" for anyone who dares disagree makes me even more reluctant to accept it.
Pair programming is about getting together, thinking and knocking out some code that both programmers agree is the best solution.
Which is done in normal programming too. Just because you don't share a desk and computer 40 hours a week doesn't mean there is no communication.
Two decent programmers sitting together pair programming will set out some good, robust code with a lot less bugs as the other is pointing out problems as they go.
And your evidence for this is, compared with two decent programmers who don't work together 40 hours a week? How do they compare on productivity more generally?
I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.
I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.
They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming
I think this is one extreme to the other - I think pair programming is bad for many reasons, but that doesn't mean I can't communicate. It's important to be able to write documents, communicate with other developers, managers, customers, and so on. But that doesn't mean I want to have to be conversing 40 hours a week for everything I do.
I might as well turn it the other way round and say that someone who thinks that communication is important is incapable of working on their own. Obviously, that would be unfair too - it's most effective to balance these things, rather than being at one extreme.
If you watch large teams of programmers, the managment actually force the developers to write slow code, claiming that maintainability is more important than any other factor!
I don't see why it should be one or the other - maintainability is important, as is using optimal algorithms. Fast algorithms can still be written in a clear and understandable manner.
True, though note this whole thread started because someone saw a crime stat for a village, and claimed this was due to gun control. So the whole premise of this thread is flawed.
Completely irrelevant. The US rate of murder is vastly higher than the UK's.
The OP made the claim that he'd rather have the US's crime rate than the UK's - I disagree. Making up phantom statistics such as claiming how guns are only used to kill burglars is completely bogus.
Let's have evidence, not made up claims. Otherwise I might as well claim it's better with gun control because then there's no crime at all. And are you seriously suggesting that if guns are allowed, the burglars won't have guns, or if they do, somehow the house owner will always win in a gunfight, despite the burglar having the element of surprise, being less concerned about shooting first, and likely have more experience at using guns in conflict? Yeah right.
I don't get it. If there's a story about authoritarianism in the UK, we get "OMG if only you had guns, you could stop this sort of thing!" (which itself is laughable, given the US also has authoritarianism problems), but when a group of angry villagers do use force to prevent this happening, that's wrong too?
Unfortunately stopping the state is a bit harder than chasing a private car out of town. How many authoritarian Government laws have you overturned, OOI?
Were they paintings in the scene, or a close up shot? Things like this could matter for issues such as fair use - the latter is basically making a duplication of a copyrighted image, whilst the former example, such as a photo taken from a van, results in a lower resolution poorer quality results. So these aren't necessarily comparable.
Also note that Wikipedia often has tighter rules, such as wanting images to be free.
Yes, because obviously everyone in Britain fully approves of CCTV everywhere.
Oh wait, they don't. And we have no idea what the viewpoint is of the people in this story.
And if it's on Street View, it's viewable by everyone. Government, corporations, individuals (wherever they live). I'm not sure where you get the idea that only neighbours can view it? Indeed, neighbours can just look out the window, so obviously they don't have a problem with that. I'm not saying CCTVs are good, nor do I agree with the moronic villagers in this story, but clearly, the number of people who can view any given CCTV camera (especially all those owned privately) is vastly smaller than the number of people who can access Google. It doesn't even come remotely close.
Slashdot Mirror
most mobile phones, from free up through the $300 models with WinCE on them, have just plain horrid UIs. the iPhone came along and, far from being perfect or even close to it, didn't totally suck. and people were amazed, and wanted to know why their phone didn't not suck.
Windoze suck! Amiga rulez!
So you think they suck, and the Iphone doesn't - that's an assertion of an opinion, can you tell us why, with evidence or examples?
As an example: my phone's UI doesn't suck. Good things about it are that it can copy and paste, and if I want to run applications from a unofficial site, or use it as a modem ("tethering"), it doesn't need to be hacked (it Just Works). All good interfaces have objective reasons why they are good - I would be curious for some examples?
Er, I don't think the issue is about assigning "fault" or "blame", because it means we get a bad mark or something. It's about how messed up we're going to be due to climate change, and what if anything we can do about it.
Now can Man be flexible enough to survive it? That is the better question.
Which is, indeed, the question people are asking.
So for your proof I would stay away from the age old 9 out to 10 scientist agree mantra, as it is not a formal way of proving anything.
You mean the bit where he said: "But you've made an even more fundamental mistake. Science isn't democratic-- it's about evidence", and then presented a load of evidence?
So, let's see your evidence.
in the UK we now even have police adverts pretty much telling people to denounce their neighbors
There's one of these on the billboard next to my house. I was amused to see someone has put printed stickers over the police logo reading "BOLLOCKS", and another one such that it reads "Confidential BOLLOCKS Hotline".
I'm not sure if this is just random vandalism, or part of some campaign. (The stickers keep changing positions every few days, too.)
And the 10 years "bollocks" is not bollocks - it's based on the freakin' Quake engine, which was created 13 years ago. Sure, bump-mapping and dynamic lighting is great, but hardly on-par with the shed-loads of further advances that are present in closed-source games.
You are conflating two issues. Yes, I'm sure that this game isn't comparable to what's possible in 2009 commercial engine, but these extra features are way beyond what Quake offered 13 years ago. More accurate might be to say under 5 years ago (taking Doom 3 as a rough benchmark). If you want to bitch that the game is 5 years old comparable to commercial engines, go right ahead, but please don't make false claims about it being 13 years old (the fact that it was originally based on a 13 year old engine is irrelevant. There are modern commercial engines that were originally based on the Quake engine, or you might as well whine that Linux is based on code that is 18 years old...)
By your reasoning, if we can handwave these extra features away, this would make Doom 3 no more advanced than Quake 1!
(I'm not sure why this is pitched as an open vs closed debate anyway. The problem isn't being open, it's being non-commercial. Yes, if you spend millions of dollars and have a team of programmers working full time for 2 years or more, you'll get better results than what people can achieve in their spare time. That's hardly surprising in any case, and especially makes a difference when graphics technology moves so fast. But I do think it is nice that the improvements trickle down - so what we thought of as cutting edge, that required millions of dollars just a few years ago, is now available in open source engines for free.)
Well in that case it's TFS and TFA that are misleading - do not take this as representative of open source. E.g., check out http://www.ogre3d.org/gallery/ for some decent screenshots from an open source engine.
The technology is also more comparable to Doom 3 than Quake 2 (it's just that the screenshots on TFA mostly don't seem to show them very well - even the screenshots from version 1 4 years ago showed realtime shadows for example, but for some reason these are disabled in most of the screenshots on the latest article!)
Although it was originally Quake 1 they started with, it looks like they've made major changes to it, adding in newer technology (e.g., dynamic lighting and realistic shadows, which is more comparable to Doom 3 than Quake 1).
I must admit, I was a bit confused. A lot of the screenshots in TFA look rather crappy, no different to the Quake 1 or 2, and don't seem to show off what the engine's really capable of. There's no evidence of anything newer such as dynamic shadows (the lighting on the walls could easily be precomputed lightmaps).
But go to the older article one year ago, and there are much better graphics - e.g., here you have realtime shadows, and what looks like bloom effect, and possibly bump mapping on the walls. There is one screenshot in the latest article that shows realtime shadows from a character, but it's rather hard to see in the screenshot. It seems odd why they released this latest batch in order to show its "impressive graphics".
There is also a lot more in the way of open source graphics engines - e.g., projects like OGRE (check out the Gallery).
Nonsense. This is like saying a militant atheist is a "Christian", because someone splashed water on their head as a baby, they had christian parents, and were forced to go to "christian" school.
If we define one's religion not by that person's belief or identity, but by someone else's actions and definitions, then we get into all sorts of nonsensical situations. Consider, if I decide that me shaking your hand whilst I'm dressed up as a pirate makes you a member of the Church of the FSM, and that you're "not really permitted to leave", does that make it true?
There is no such thing as a muslim child, just as we would not talk about a Marxist or Keynesian child.
Although I note that whilst usually religious organisations promote these definitions in order to inflate their numbers and force religion onto children, I suspect you're instead taking advantage of anti-Islam viewpoints, in order to make Obama look bad. But I don't really care about the politics here, just your nonsensical non-consensual definition of labelling. Who cares if he is a muslim anyway? Christian or muslim, or Church of Intel, just so long as he keeps his religion out of politics, unlike a certain recent President...
But I'm not talking about two people working on the same area - yes, the man month is mythical, but that means in the sense of having two people working on the same issue. In large projects such as where I work, we have people working in very different areas, and communication directly between these people is not required (of course, we do communicate as when necessary, but clearly, the "pair" will still need to communicate to other pairs of programmers too, so there is no difference here).
Basically, if you have enough money that you can double the number of employees, I'll agree that pair programming is worth trying. But the idea that most programmers in a development team result "in no increase in the amount of work performed" is ludicrous - if that's true, then you've got more serious problems that need resolving, that have nothing to do with not pair programming. (Given the book you quote, I suspect you're misquoting - as I say, the mythical man month is to do with adding extra programmers to a problem, and not companies that simply have more than one employee. By your reasoning, a company with 1,000 employees is mostly useless, and only slightly more productive than one with a handful of employees!)
Indeed, if that was really true, why not extend the concept? I mean, if we have 10 developers split into pairs, surely by your logic, the 4th and 5th pairs don't really do very much. So perhaps we should all group them up - just have ten people sitting round a desk, working on the same bit of code. That'll be much more productive right? It must be true, because of the Mythical Man Month!
The idea enables teams that are twice as large
Most companies don't have the resources to suddenly double their development size. I think you're making the assumption that most places are already overstaffed by a factor of 2, and hence people are already doubled up in the same bits of code, where they don't really help. Yes, there the Mythical Man Month applies, and pair programming would be worth trying, as I say.
But there are plenty of companies that aren't like that. My experience is that places are more likely to be understaffed, and need as many new developers as possible. At these places, pair programming is the last thing you want.
and if you pair-program then it's easier to design, to write and to get live with minimal bugs.
Of course, two people may well be better than one, but that's obvious.
What you need to show is that pair-programming is more than twice as productive - in terms of adding functionality and reducing bugs.
What few people realize though is that pair programming is boring for the person without the keyboard. It's mind-numbingly boring. It's like watching someone do mathematics homework for a whole day. I enjoy programming, but watching other people code is a lot less fun.
Yes, exactly. Even if somehow pair programming really was more than 100% of an improvement, thus making it worthwhile, from an employee point of view, it would be far less an attractive job. This isn't about being a good or bad programmer, it's just that my preferred job choice was that of "programmer", not "sit and watch someone else code".
finding that a 50% speedup over a single programmer, which is in the same order as two programmers working independently
Am I missing something? Given that most non-trivial companies can parallelise their workload for at least two people, I would expect two independent programmers to be 100% faster than a single programmer.
So, yeah, basically the point is that while two people at separate keyboards may produce a larger volume of code
It's not about "volume of code", it's about functionality.
And we haven't even touched on the fact that pair programming spreads knowledge of the design of the codebase the team is working on
All this can be done without pair programming too. The reason it usually doesn't happen in most companies is because they don't have the resources to hire twice as many people, so pair programming isn't an option there anyway. If companies could hire twice as many people, then even with non-pair programming, you could still double people up in each area of functionality, thus spreading the knowledge base.
Pair programming only compares well to places with half as many developers, or a straw man version of non-pair programming where everyone works in a sealed box and never communicates with anyone else.
I entirely agree. Of course, a second perspective is good, but you can obviously get that without resorting to pair programming, simply by discussing with over developers. Moreover, pair programming has the problem that you both have been looking from it with the same perspective, having gone over the same route, and making the same mistakes. The idea that pair programming is a different perspective is rather ludicrous, when you've both been working together constantly - I'd argue getting a different fresh perspective, for someone who isn't biased by having done and seen everything that you've done, is better.
I think there are also other issues. Working together having to explain every thought you have to the person looking over your shoulder does make things more stressful for a programmer. No doubt the AC will respond with "OMG that makes you a crap programmer!", but this is an important thing to take into account. Whilst I am quite capable of communicating with other developers, one of the reasons I like programming is that I prefer working a reasonable amount of time on my own. I imagine this is true of many programmers, and indeed, other professions such as authors. Not to mention other issues, such as losing a great deal of flexibility now having to go around with the other person (e.g., having to take lunch break at exactly the same time, sharing desk and computer). It's one extreme to the other - a job traditionally focused on individual work, going to one that requires far more constant social interaction than most other jobs. If programmers don't like that, they'll be more likely to look elsewhere, and that's something companies have to take into account too.
So you can't catch bugs when working outside of pair programming? Sounds like a communication problem where you don't discuss the functionality with other developers, or not critically thinking about the problem from another perspective.
If a programmer can't deal with pair programming them they're a very poor programmer.
Where did he say he couldn't deal with it?
I might as well claim "If a programmer can't deal with programming on his own, they're a very poor programmer".
Is that fair? Of course not. The debate here is about which is better, and I see no evidence that pair programming is better than two programmers working normally.
The fact that advocates of pair programming can't argue their case, other than resorting to ad hominems of "You must be a crap programmer" for anyone who dares disagree makes me even more reluctant to accept it.
Pair programming is about getting together, thinking and knocking out some code that both programmers agree is the best solution.
Which is done in normal programming too. Just because you don't share a desk and computer 40 hours a week doesn't mean there is no communication.
Two decent programmers sitting together pair programming will set out some good, robust code with a lot less bugs as the other is pointing out problems as they go.
And your evidence for this is, compared with two decent programmers who don't work together 40 hours a week? How do they compare on productivity more generally?
I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.
I'd suggest that you're a poorer programmer than you think and that you should rethink how you go about problem solving.
They think their job is to produce code and avoid communicating with others as much as possible. Witness the common reaction to the idea of pair programming
I think this is one extreme to the other - I think pair programming is bad for many reasons, but that doesn't mean I can't communicate. It's important to be able to write documents, communicate with other developers, managers, customers, and so on. But that doesn't mean I want to have to be conversing 40 hours a week for everything I do.
I might as well turn it the other way round and say that someone who thinks that communication is important is incapable of working on their own. Obviously, that would be unfair too - it's most effective to balance these things, rather than being at one extreme.
If you watch large teams of programmers, the managment actually force the developers to write slow code, claiming that maintainability is more important than any other factor!
I don't see why it should be one or the other - maintainability is important, as is using optimal algorithms. Fast algorithms can still be written in a clear and understandable manner.
True, though note this whole thread started because someone saw a crime stat for a village, and claimed this was due to gun control. So the whole premise of this thread is flawed.
Completely irrelevant. The US rate of murder is vastly higher than the UK's.
The OP made the claim that he'd rather have the US's crime rate than the UK's - I disagree. Making up phantom statistics such as claiming how guns are only used to kill burglars is completely bogus.
Let's have evidence, not made up claims. Otherwise I might as well claim it's better with gun control because then there's no crime at all. And are you seriously suggesting that if guns are allowed, the burglars won't have guns, or if they do, somehow the house owner will always win in a gunfight, despite the burglar having the element of surprise, being less concerned about shooting first, and likely have more experience at using guns in conflict? Yeah right.
And I'd rather have money on trees and a pony!
See, look how much better the UK's policy on guns is! (It's easy to win an argument when you can pull stats out your arse.)
Because the US crime rate is so much lower!
Yes, it would clearly be so much better if we had the US's "3 murders in 6 weeks" instead. Or more like 6 days.
Er no, we don't like the state doing it either.
I don't get it. If there's a story about authoritarianism in the UK, we get "OMG if only you had guns, you could stop this sort of thing!" (which itself is laughable, given the US also has authoritarianism problems), but when a group of angry villagers do use force to prevent this happening, that's wrong too?
Unfortunately stopping the state is a bit harder than chasing a private car out of town. How many authoritarian Government laws have you overturned, OOI?
Were they paintings in the scene, or a close up shot? Things like this could matter for issues such as fair use - the latter is basically making a duplication of a copyrighted image, whilst the former example, such as a photo taken from a van, results in a lower resolution poorer quality results. So these aren't necessarily comparable.
Also note that Wikipedia often has tighter rules, such as wanting images to be free.
Yes, because obviously everyone in Britain fully approves of CCTV everywhere.
Oh wait, they don't. And we have no idea what the viewpoint is of the people in this story.
And if it's on Street View, it's viewable by everyone. Government, corporations, individuals (wherever they live). I'm not sure where you get the idea that only neighbours can view it? Indeed, neighbours can just look out the window, so obviously they don't have a problem with that. I'm not saying CCTVs are good, nor do I agree with the moronic villagers in this story, but clearly, the number of people who can view any given CCTV camera (especially all those owned privately) is vastly smaller than the number of people who can access Google. It doesn't even come remotely close.
Good point.
But nevermind schools - this is the UK, where taking photos of any buildings risks you getting reported or arrested as a terrorist... (e.g., see http://boingboing.net/2009/01/11/another-london-photo.html ; we even have advertising campaigns against it: http://www.boingboing.net/2008/03/04/london-cops-declare.html ).