As another pointed out, Russia isn't anywhere near the first country to do this; in fact, doesn't the European Union require it Union-wide?
The EU directive isn't about local control, but about data protection standards -- non-EU countries can apply to be considered equivalent if their laws have suitable protections. Although the EU did kind of give up the moral high ground when it granted equivalent status to Israel, mere months after Mossad sent a death squad into one of the Arab countries on cloned EU passports....
As Scottish nationalist (small n), I'm not exactly the BBC's number 1 fan. But complying with the law doesn't mean taking it down in this instance, as the law states that figures in the public spotlight are fair game.
My brother is a health and safety officer for a large private-sector industrial facility. When new equipment and materials are brought on-site, he has to perform risk assessments to assure they comply with the appropriate legislation, and this is at his employers' expense. Why should Google be any different? Not knowing what's inside a box is a poor excuse for lack of due diligence. In fact, it's negligence.
Laugh all you like, but the result will just be that half the cryptozoologists take up the belief that yeti-alikes are hybrids caused by drunken idiots sh*gging horses and polar bears. (How any man would get that close to a polar bear is beyond me, though.)
In 2012, researchers at the University of Oxford in the United Kingdom and the Museum of Zoology in Lausanne, Switzerland, put out a call for hair samples thought to be from anomalous primates
Correct me if I'm wrong, after all I'm only an American, but those places aren't in America?
Did they call for the hairs because they believed they would be genuine bigfoots, or to prove that they weren't...?
Ya, I bet it's hard to be religious in a country that has in most recent history tried to eradicate a religious population. You just don't know when your religion is going to be next...
Of course, it's equally likely that the next scapegoat for all society's ills will be atheists and secularists -- moral decay leading to the breakdown of the family, and messing up the financial markets with their joint loans hitting divorce; sex outside marriage leading to single-parent families, hence benefit claims; unmarried co-habiting couples pushing up the price of housing...
Not that I believe any of this -- the above is just a portfolio piece that I can use in my job application when the next great dictator wants a minister for propaganda.:-)
I suspect Google's playing at what is called "malicious compliance". They don't like the law, because they don't like spending money, just making it. So what they really want is to wind up the news outlets to turn them against the law, because only the press has the power to form public opinion. So I'm very glad to see the BBC pushing back rather than swallowing the bait.
Calling a spreadsheet a useful tool is like calling a blank piece of paper a useful tool. It is true. However, an enterprise that ran entirely on blank sheets of paper that individual employees used in whatever way they felt inclined would be a complete disaster, because the company's information would be inconsistent and unstructured. And yet we allow people to use spreadsheets, leaving their data inconsistent and unstructured.
The limit of tasks that should be done on spreadsheets is ad hoc calculations up to A6 size. Anything with any sort of tables and references should be done in a not-quite-a-database-but-not-really-a-spreadsheet type app.
Innovation in spreadsheets? The only innovation spreadsheets need is a bullet in the head. Spreadsheets are the worst of bad programming practices opened up to the wider public. Kill them. Kill them with fire.
Regular expressions may be a bit arcane superficially, but once you know them, you know them, and they're pretty quick to decode.
In a lot of internet debates (ie massive fights) about human-readability of code, a false distinction is made between natural-language-like languages and non-human-readable languages. Regexp is a mini-language that is small, regular and learnable. It's not natural-language-like, but once taught is human readable in the same way a mathematical formula is -- not necessarily instantly comprehensible, but very quick to read.
The argument for mathematical languages has always been the compactness of a formula, and the fact that a formula is a semantic description. The equivalent in normal coding practice is to write out all the steps for performing the formula. Well, an arbitrary sequence of steps, as there are always multiple ways to approach the calculation of any formula with more than two terms.
The natural-language-like language is less readable, because it has less semantic content, hence our need for comments. Formulas are shorter and need far fewer comments. With a regexp, I can name it "US_date_format", and it's documented. Writing a piece of C code to explicitly identify text strings containing dates in the US format would be long and arduous, and individual steps would be isolated, making the overall function of the procedure harder to verify.
The original author is looking at the part of the problem that gets the most attention, but not at the part that causes the most problems. He's looking at programming languages and their expressive problems. Those are real, but they're not why large programs break. Large programs usually break for non-local reasons. Typically, Part A was connected to Part B in some way such that an assumption made by part B was not satisfied by part A.
I believe the author ascribes most non-local problems to "incidental complexity". Incidental complexity introduces bugs, which in turn make code less predictable, which causes non-local problems. Furthermore, Grainger focuses on carrying out non-destructive data transforms, à la functional programming, which alone should wipe out a large percentage of non-local problems, as you shouldn't find yourself having to chase down any erroneous value-change bugs.
In fact, Grainger's whole point is about the attitude that you express being typical -- we focus on the fixing the problems created by the imperative programming paradigm within the imperative programming paradigm, rather than simply replacing the imperative paradigm with something more appropriate.
This essay is basically what all our CS lecturers have been saying for the last 40 years....
he chose two rather bad examples. His math formula is as likely to look like gobbledygook to a non-math person as the program is.
Ah, but the thing is that the back-end that allows the formula to be shown in a mathematical notation is an abstracting backend. In current programming, the formula has a machine representation that maps to a single visual representation. Once we start storing abstract forms, we can let the IDE present it according to the user's wishes and knowledge.
These days, I see a lot of code that CANNOT be read without using an "IDE".
... and herein lies one of computing's biggest paradoxes. We are obsessed with plaintext as being the only suitable format for code because it is "human readable", yet almost every coder on a project of any scale uses an ID with autocompletion etc. The IDE would be much easier to use if it was freed from the constraints of plain text -- rather than linear code ordering, we could order instead by dependencies, and display on screen left-to-right ordered by call when viewing the logic. Away from plaintext, we could start using standard mathematical notation for mathematical problems (see also TFA). We could eliminate most typo bugs by simply not allowing an undefined keyword or label to be used. And we could implement spreadsheet/database-style table displays for the setting of nested arrays of data, rather than faffing around with bracket-matching and erroneous commas.
We need computing to be more closely bound to the IDE.
I was always a pretty competent coder, but I hardly ever code these days. I'm perfectly happy thinking in logical terms -- my problem is keeping the logic in my head while I spend several days coding around the logic. When I'm fighting with syntax, eccentricities in library execution etc, I have to not only think about the problem logic, but also the language logic, the library logic, etc etc etc. This is what Grainger calls "incidental complexity" -- everything other than the problem at hand. It distracts from solving the actual problem, and it places a massive unnecessary cognitive load on the coder. It becomes frustrating and limiting, and you sometimes find at the end of the day that you haven't coded exactly what you intended to, because you were so distracted. But all that incidental complexity means that it's very difficult to unpick your code and rewrite it to what you wanted. Incidental complexity is very bad both for the experienced and inexperienced coder.
Yes, and someone suffered to bring you that video... just not the uploader. There is more suffering in a vapid Hollywood blockbuster than in a 3 minute homemade short, but the repeated uploading of the same blockbuster does not constitute new art.
You've never been involved in any commercial film production then: it's a long, arduous process. Or code development: it's also a long, arduous process. Perhaps in these cases it's the toolchain that's at fault, but at present, suffer you will. But there's nothing that you can do to stop your fingers hurting if you want to learn the guitar to a really high level.
The only legal way to run this sort of service and not be liable for it's misuse is to design it in such a way that you cannot see what is being stored at all.
YANAL. The DMCA states that companies must take reasonable steps to prevent reuploading. Designing a system with the express purpose of not being able to prevent uploading would be thoroughly illegal.
As another pointed out, Russia isn't anywhere near the first country to do this; in fact, doesn't the European Union require it Union-wide?
The EU directive isn't about local control, but about data protection standards -- non-EU countries can apply to be considered equivalent if their laws have suitable protections. Although the EU did kind of give up the moral high ground when it granted equivalent status to Israel, mere months after Mossad sent a death squad into one of the Arab countries on cloned EU passports....
As for restricting culture, we still have actual people to interact with, so not to worry.
Not for long -- Russia has made emigration almost illegal, but none of the international press have seen fit to pick up on this.
In Soviet America? .. :D
In Soviet America, witch hunts you, Sen. McCarthy.
They don't like the law, because they don't like spending money, just making it.
As opposed to all of those other companies that love spending money and hate making it?
Exactly the same, of course. My point is just that we shouldn't paint Google as the "good guys" for opposing a law that costs them hard cash.
As Scottish nationalist (small n), I'm not exactly the BBC's number 1 fan. But complying with the law doesn't mean taking it down in this instance, as the law states that figures in the public spotlight are fair game.
My brother is a health and safety officer for a large private-sector industrial facility. When new equipment and materials are brought on-site, he has to perform risk assessments to assure they comply with the appropriate legislation, and this is at his employers' expense. Why should Google be any different? Not knowing what's inside a box is a poor excuse for lack of due diligence. In fact, it's negligence.
No, because not deleting would be complying with the law.
Don't forget about the Polar Bears Drowning ....
If the polar bears aren't having trouble in the North Pole, why have they all started moving to Tibet to f*ck the yetis?
Laugh all you like, but the result will just be that half the cryptozoologists take up the belief that yeti-alikes are hybrids caused by drunken idiots sh*gging horses and polar bears. (How any man would get that close to a polar bear is beyond me, though.)
If the chemtrails didn't have genitals, how would they be able to impregnate a horse, a woman and a polar bear with bigfoot sperm?
In 2012, researchers at the University of Oxford in the United Kingdom and the Museum of Zoology in Lausanne, Switzerland, put out a call for hair samples thought to be from anomalous primates
Correct me if I'm wrong, after all I'm only an American, but those places aren't in America?
Did they call for the hairs because they believed they would be genuine bigfoots, or to prove that they weren't...?
Ya, I bet it's hard to be religious in a country that has in most recent history tried to eradicate a religious population. You just don't know when your religion is going to be next...
Of course, it's equally likely that the next scapegoat for all society's ills will be atheists and secularists -- moral decay leading to the breakdown of the family, and messing up the financial markets with their joint loans hitting divorce; sex outside marriage leading to single-parent families, hence benefit claims; unmarried co-habiting couples pushing up the price of housing...
Not that I believe any of this -- the above is just a portfolio piece that I can use in my job application when the next great dictator wants a minister for propaganda. :-)
I suspect Google's playing at what is called "malicious compliance". They don't like the law, because they don't like spending money, just making it. So what they really want is to wind up the news outlets to turn them against the law, because only the press has the power to form public opinion. So I'm very glad to see the BBC pushing back rather than swallowing the bait.
Calling a spreadsheet a useful tool is like calling a blank piece of paper a useful tool. It is true. However, an enterprise that ran entirely on blank sheets of paper that individual employees used in whatever way they felt inclined would be a complete disaster, because the company's information would be inconsistent and unstructured. And yet we allow people to use spreadsheets, leaving their data inconsistent and unstructured.
The limit of tasks that should be done on spreadsheets is ad hoc calculations up to A6 size. Anything with any sort of tables and references should be done in a not-quite-a-database-but-not-really-a-spreadsheet type app.
Innovation in spreadsheets? The only innovation spreadsheets need is a bullet in the head. Spreadsheets are the worst of bad programming practices opened up to the wider public. Kill them. Kill them with fire.
Regular expressions may be a bit arcane superficially, but once you know them, you know them, and they're pretty quick to decode.
In a lot of internet debates (ie massive fights) about human-readability of code, a false distinction is made between natural-language-like languages and non-human-readable languages. Regexp is a mini-language that is small, regular and learnable. It's not natural-language-like, but once taught is human readable in the same way a mathematical formula is -- not necessarily instantly comprehensible, but very quick to read.
The argument for mathematical languages has always been the compactness of a formula, and the fact that a formula is a semantic description. The equivalent in normal coding practice is to write out all the steps for performing the formula. Well, an arbitrary sequence of steps, as there are always multiple ways to approach the calculation of any formula with more than two terms.
The natural-language-like language is less readable, because it has less semantic content, hence our need for comments. Formulas are shorter and need far fewer comments. With a regexp, I can name it "US_date_format", and it's documented. Writing a piece of C code to explicitly identify text strings containing dates in the US format would be long and arduous, and individual steps would be isolated, making the overall function of the procedure harder to verify.
Uhuh. And what detail do you want the comments to have? If there are more comments than code, the code isn't clear enough.
Yeah... you might just have to go to a real restaurant.
(Incidentally, it's a pretty good analogy.Human meat is about as palatable to a shark as a Big Mac is to a man with fully-functioning tastebuds.)
The original author is looking at the part of the problem that gets the most attention, but not at the part that causes the most problems. He's looking at programming languages and their expressive problems. Those are real, but they're not why large programs break. Large programs usually break for non-local reasons. Typically, Part A was connected to Part B in some way such that an assumption made by part B was not satisfied by part A.
I believe the author ascribes most non-local problems to "incidental complexity". Incidental complexity introduces bugs, which in turn make code less predictable, which causes non-local problems. Furthermore, Grainger focuses on carrying out non-destructive data transforms, à la functional programming, which alone should wipe out a large percentage of non-local problems, as you shouldn't find yourself having to chase down any erroneous value-change bugs.
In fact, Grainger's whole point is about the attitude that you express being typical -- we focus on the fixing the problems created by the imperative programming paradigm within the imperative programming paradigm, rather than simply replacing the imperative paradigm with something more appropriate.
This essay is basically what all our CS lecturers have been saying for the last 40 years....
he chose two rather bad examples. His math formula is as likely to look like gobbledygook to a non-math person as the program is.
Ah, but the thing is that the back-end that allows the formula to be shown in a mathematical notation is an abstracting backend. In current programming, the formula has a machine representation that maps to a single visual representation. Once we start storing abstract forms, we can let the IDE present it according to the user's wishes and knowledge.
These days, I see a lot of code that CANNOT be read without using an "IDE".
... and herein lies one of computing's biggest paradoxes. We are obsessed with plaintext as being the only suitable format for code because it is "human readable", yet almost every coder on a project of any scale uses an ID with autocompletion etc. The IDE would be much easier to use if it was freed from the constraints of plain text -- rather than linear code ordering, we could order instead by dependencies, and display on screen left-to-right ordered by call when viewing the logic. Away from plaintext, we could start using standard mathematical notation for mathematical problems (see also TFA). We could eliminate most typo bugs by simply not allowing an undefined keyword or label to be used. And we could implement spreadsheet/database-style table displays for the setting of nested arrays of data, rather than faffing around with bracket-matching and erroneous commas.
We need computing to be more closely bound to the IDE.
I was always a pretty competent coder, but I hardly ever code these days. I'm perfectly happy thinking in logical terms -- my problem is keeping the logic in my head while I spend several days coding around the logic. When I'm fighting with syntax, eccentricities in library execution etc, I have to not only think about the problem logic, but also the language logic, the library logic, etc etc etc. This is what Grainger calls "incidental complexity" -- everything other than the problem at hand. It distracts from solving the actual problem, and it places a massive unnecessary cognitive load on the coder. It becomes frustrating and limiting, and you sometimes find at the end of the day that you haven't coded exactly what you intended to, because you were so distracted. But all that incidental complexity means that it's very difficult to unpick your code and rewrite it to what you wanted. Incidental complexity is very bad both for the experienced and inexperienced coder.
Yes, and someone suffered to bring you that video... just not the uploader. There is more suffering in a vapid Hollywood blockbuster than in a 3 minute homemade short, but the repeated uploading of the same blockbuster does not constitute new art.
You've never been involved in any commercial film production then: it's a long, arduous process. Or code development: it's also a long, arduous process. Perhaps in these cases it's the toolchain that's at fault, but at present, suffer you will. But there's nothing that you can do to stop your fingers hurting if you want to learn the guitar to a really high level.
The only legal way to run this sort of service and not be liable for it's misuse is to design it in such a way that you cannot see what is being stored at all.
YANAL. The DMCA states that companies must take reasonable steps to prevent reuploading. Designing a system with the express purpose of not being able to prevent uploading would be thoroughly illegal.