You seem to wilfully ignore the fact that Islamist terrorism kills, rapes, and enslaves far more Muslims than non-Muslims (by a factor of at least 8 at last count), and most Muslims know it. ISIS is the self-declared enemy of the vast majority of the Islamic world.
This is an outsider opinion, so take it for what it's worth, but it seems to me that one possible solution that isn't being talked about is devo-max for England.
If everyone had something closer to equal representation on equal terms, like a federation, that would go some way to repairing the Union. But Brexit has been triggered, so that may not even matter now.
It has now essentially turned its back on one of the constants of British foreign policy since Tudor times.
That's one way of looking at it. The other way of looking at it is that British foreign policy since Tudor times has been to ensure that no single entity ever came to power in Europe, and destabilising the EU is a continuance of that policy.
I work with (multi-terabyte, not multi-petabyte) GIS databases. I am also a Haskell programmer (though not for my day job) so MapReduce doesn't scare me off at all. It's very hard to see how MapReduce specifically would help large-scale GIS.
The main benefit of MapReduce for most problems isn't the programming model, it's the principle "move your code to where the data is" in a way that's agnostic to precisely where the data is. When you have big data, you need to do that. Precisely what that code does is a secondary concern.
As long as I'm entering into the contract with the manufacturer voluntarily, there is really nothing justifying your (and the EFF's) concern about it...
If you want to freely enter a contract to effectively hire a smart shovel, that's your business. That, however, would not be a sale.
Google Earth is universally reviled amongst geographers for assuming the Earth is a sphere, thus undoing 400 years of geography. Thanks to that, a thousand apps written by people who know nothing about geography have gone with Google Earth's projection, compounding the problem even further. There is an inside joke to the effect that Google's solution is to patch the Earth.
The coordinate system is formally known as "Google Mercator", to distance it from your great-great-great-great-great-etc-grandfather's Mercator.
I'm sorry, but a program that's thousands of methods and small classes is not clearer than a program with fewer, larger, structures. Yes, write code for Humans, not machines, I agree. BUT remember your other programmers want to understand your program - not any one individual method - so making each method simple only moves the complexity into the interrelationships between methods, something considerably harder to understand.
Actually, I agree with the author on this one, but the title is wrong. It should be something more like: "Write your code under the assumption that dozens of mediocre programmers will be eventually responsible for maintaining it."
This "thousands of 15 line methods and small classes" approach is the only way that we know of, so far, to scale up codebase to dozens or even thousands of mediocre programmers. It sucks, but really good programmers are hard to find.
I have heard plenty of bad things, but does anyone have anything good to say about Java?
Absolutely! Off the top of my head:
Java broke the logjam in the open source world (though it wasn't called "open source" at the time). Before Java, pretty much everything was in C (and maybe a little Tcl). The Java hype opened up the open source world to all languages. (Note that Perl 5 dates from around the same time as Java 1, and I don't want to discount its relevance, but while Perl and CPAN would have gone on to influence other languages like Perl, it didn't step into C's space like Java did.)
Java broke a significant logjam in programming language research. Almost every single piece of research that has happened in managed execution environments, modern concurrent garbage collection, JIT compilation, reflective virtual machines, and so on are largely thanks to Java.
On that note, in 20+ years, there has never (to my knowledge) ever been a security hole in the Java platform which was caused by the JVM or the Classloader. Plenty in the SecurityManager library, but none in the JVM infrastructure.
Modula 2 probably did the worst of the four, vanishing from sight.
That's not entirely fair, given that Modula 3 is in the top three. Sure, it was given a curly-braces syntax and renamed "Java", but it was basically Modula 3 with a new skin.
In ten days there was no time to have a full complement of types, in fact Javascript can't handle integers. That's a problem because, for example it means 9999999999999999 is equal to 10000000000000000. Floating point comes with all kinds of errors. You're actually not supposed to ever compare to floating point numbers for equality, you're supposed to check whether the difference between them is small. Since JavaScript only HAS floating point numbers, it can't tell whether or not two numbers are equal, in the general case.
Oh, dear.
First off, the main alternative in the scripting world is the union of monotypes model, where a number could be a float, integer, or string depending on context, and the language will silently cast between them as needed. The unpredictability of this model is, in my experience, the cause of far more errors than floating point misuse. JavaScript numbers often aren't what you want, but the vast majority of the time you know exactly where you stand with them.
Secondly, you can and sometimes should compare floating point numbers for equality, and in JavaScript use it's typically the right thing to do. This is the 21st century, and the screwed-up numerics of x87's 80 bit registers are far behind us. A 32-bit integer fits losslessly in a 64-bit floating point number. If you do ring operations (e.g. the vast majority of what happens in CSS layout computations) and don't overflow, they will behave exactly as an integer would. If they don't, send your compiler or FPU back because something is broken.
There are many bad design decisions in JavaScript, but this one was smart.
Keep in mind, though, -1 is less than Number.MIN_VALUE, and MAX_VALUE is less than MIN_VALUE.
As you probably know, this behaviour was inherited from C, where DBL_MIN is famously greater than zero. Most languages since (with the notable exception of C++; see min() vs lowest() in std::numeric_limits) have corrected this mistake but it's arguable whether or not JavaScript should have attempted to do so.
Reading this, perhaps we should keep in mind it is based on pull requests on public Github repositories; that's counting how much these languages are *shared*, not how much they are *used*.
Oh... so you're saying the several squillion single-function dependencies that are pulled any time you try to do anything nontrivial in node.js are counted separately every time you deploy it on a new machine? Yeah, that would explain it.
No, this is a submission that's clearly trying to divide engineering into an us-versus-them situation, in this case along gender lines.
Uhm... no. There were two submissions merged; the second one-sentence summary may be excerpted from something longer. For the "main" submission, there are a number of differences mentioned in TFS (USA vs India, NASA vs ISRO, expensive vs cheap, slow vs fast development time), and the comment section has chosen to focus on one particular difference to the exclusion of others. That says more about the comment section than it does about TFS.
I've witnessed escalating shouting matches between neighbours which end up with the police arriving. The law becoming involved in such cases is not new.
Just like the McDonald's coffee case, a lot of people don't get why this case went to trial. There were genuine disagreements on what actually happened, and it took the investigation and trial to sort it all out.
There was at least one impersonation account involved, and as such, none of the actually-threatening tweets were from Elliot. But what the case ultimately hinged on was whether or not Elliot was expected to know that the recipients were being harassed (which they undeniably were, by other people) and that because of this, what he said would cause them to legitimately fear for their safety. He had no reason to know that there was an active harassment campaign because Guthrie had blocked him, so he couldn't see it.
In the end, the correct outcome was reached. So the system works, I guess.
Certain people send rape and death threats all the time with the intent provoke a reaction. Occasionally some of them are arrested, and it's never the reaction that's the issue. It's usually the threat and possibly the stalking.
Slashdot Mirror
You seem to wilfully ignore the fact that Islamist terrorism kills, rapes, and enslaves far more Muslims than non-Muslims (by a factor of at least 8 at last count), and most Muslims know it. ISIS is the self-declared enemy of the vast majority of the Islamic world.
This is an outsider opinion, so take it for what it's worth, but it seems to me that one possible solution that isn't being talked about is devo-max for England.
If everyone had something closer to equal representation on equal terms, like a federation, that would go some way to repairing the Union. But Brexit has been triggered, so that may not even matter now.
Most programmers have more than one web browser installed on their machine.
It has now essentially turned its back on one of the constants of British foreign policy since Tudor times.
That's one way of looking at it. The other way of looking at it is that British foreign policy since Tudor times has been to ensure that no single entity ever came to power in Europe, and destabilising the EU is a continuance of that policy.
I would like to know who claimed email was dead. Someone without a job, I'm guessing.
I work with (multi-terabyte, not multi-petabyte) GIS databases. I am also a Haskell programmer (though not for my day job) so MapReduce doesn't scare me off at all. It's very hard to see how MapReduce specifically would help large-scale GIS.
The main benefit of MapReduce for most problems isn't the programming model, it's the principle "move your code to where the data is" in a way that's agnostic to precisely where the data is. When you have big data, you need to do that. Precisely what that code does is a secondary concern.
Also, if some humor-deficient mensch claims that Germans have no sense of humor [...]
I know Germans have a sense of humour. I've seen 7 Zwerge.
As long as I'm entering into the contract with the manufacturer voluntarily, there is really nothing justifying your (and the EFF's) concern about it...
If you want to freely enter a contract to effectively hire a smart shovel, that's your business. That, however, would not be a sale.
Yeah... you can't really strongarm a planet which has Illudium Q-36 Explosive Space Modulator technology.
cuz you don't want to see it?
If only there was some way we could mathematically calculate the strength and significance of a purported correlation...
Educational in the sense that Google Earth is a perfect example of how people who don't know anything about geography shouldn't be doing geography?
Google Earth is universally reviled amongst geographers for assuming the Earth is a sphere, thus undoing 400 years of geography. Thanks to that, a thousand apps written by people who know nothing about geography have gone with Google Earth's projection, compounding the problem even further. There is an inside joke to the effect that Google's solution is to patch the Earth.
The coordinate system is formally known as "Google Mercator", to distance it from your great-great-great-great-great-etc-grandfather's Mercator.
Haha, I got downvoted by a Python programmer.
Number 38 will shock you!
I'm sorry, but a program that's thousands of methods and small classes is not clearer than a program with fewer, larger, structures. Yes, write code for Humans, not machines, I agree. BUT remember your other programmers want to understand your program - not any one individual method - so making each method simple only moves the complexity into the interrelationships between methods, something considerably harder to understand.
Actually, I agree with the author on this one, but the title is wrong. It should be something more like: "Write your code under the assumption that dozens of mediocre programmers will be eventually responsible for maintaining it."
This "thousands of 15 line methods and small classes" approach is the only way that we know of, so far, to scale up codebase to dozens or even thousands of mediocre programmers. It sucks, but really good programmers are hard to find.
I have heard plenty of bad things, but does anyone have anything good to say about Java?
Absolutely! Off the top of my head:
Java broke the logjam in the open source world (though it wasn't called "open source" at the time). Before Java, pretty much everything was in C (and maybe a little Tcl). The Java hype opened up the open source world to all languages. (Note that Perl 5 dates from around the same time as Java 1, and I don't want to discount its relevance, but while Perl and CPAN would have gone on to influence other languages like Perl, it didn't step into C's space like Java did.)
Java broke a significant logjam in programming language research. Almost every single piece of research that has happened in managed execution environments, modern concurrent garbage collection, JIT compilation, reflective virtual machines, and so on are largely thanks to Java.
On that note, in 20+ years, there has never (to my knowledge) ever been a security hole in the Java platform which was caused by the JVM or the Classloader. Plenty in the SecurityManager library, but none in the JVM infrastructure.
I fear for our business when this is considered the best advice we can come up with.
BTW, I have a good title for my thing that every programmer should know: "Most things aren't objects."
Modula 2 probably did the worst of the four, vanishing from sight.
That's not entirely fair, given that Modula 3 is in the top three. Sure, it was given a curly-braces syntax and renamed "Java", but it was basically Modula 3 with a new skin.
Oh, dear.
First off, the main alternative in the scripting world is the union of monotypes model, where a number could be a float, integer, or string depending on context, and the language will silently cast between them as needed. The unpredictability of this model is, in my experience, the cause of far more errors than floating point misuse. JavaScript numbers often aren't what you want, but the vast majority of the time you know exactly where you stand with them.
Secondly, you can and sometimes should compare floating point numbers for equality, and in JavaScript use it's typically the right thing to do. This is the 21st century, and the screwed-up numerics of x87's 80 bit registers are far behind us. A 32-bit integer fits losslessly in a 64-bit floating point number. If you do ring operations (e.g. the vast majority of what happens in CSS layout computations) and don't overflow, they will behave exactly as an integer would. If they don't, send your compiler or FPU back because something is broken.
There are many bad design decisions in JavaScript, but this one was smart.
As you probably know, this behaviour was inherited from C, where DBL_MIN is famously greater than zero. Most languages since (with the notable exception of C++; see min() vs lowest() in std::numeric_limits) have corrected this mistake but it's arguable whether or not JavaScript should have attempted to do so.
Reading this, perhaps we should keep in mind it is based on pull requests on public Github repositories; that's counting how much these languages are *shared*, not how much they are *used*.
Oh... so you're saying the several squillion single-function dependencies that are pulled any time you try to do anything nontrivial in node.js are counted separately every time you deploy it on a new machine? Yeah, that would explain it.
Building a casino isn't exactly rocket science. Hell, even Trump can do it, so it can't be that hard.
No, this is a submission that's clearly trying to divide engineering into an us-versus-them situation, in this case along gender lines.
Uhm... no. There were two submissions merged; the second one-sentence summary may be excerpted from something longer. For the "main" submission, there are a number of differences mentioned in TFS (USA vs India, NASA vs ISRO, expensive vs cheap, slow vs fast development time), and the comment section has chosen to focus on one particular difference to the exclusion of others. That says more about the comment section than it does about TFS.
I've witnessed escalating shouting matches between neighbours which end up with the police arriving. The law becoming involved in such cases is not new.
Just like the McDonald's coffee case, a lot of people don't get why this case went to trial. There were genuine disagreements on what actually happened, and it took the investigation and trial to sort it all out.
There was at least one impersonation account involved, and as such, none of the actually-threatening tweets were from Elliot. But what the case ultimately hinged on was whether or not Elliot was expected to know that the recipients were being harassed (which they undeniably were, by other people) and that because of this, what he said would cause them to legitimately fear for their safety. He had no reason to know that there was an active harassment campaign because Guthrie had blocked him, so he couldn't see it.
In the end, the correct outcome was reached. So the system works, I guess.
Certain people send rape and death threats all the time with the intent provoke a reaction. Occasionally some of them are arrested, and it's never the reaction that's the issue. It's usually the threat and possibly the stalking.
It's not clear what statute they claim was violated here [...]
It's not in TFA, but it's also not hard to find. The guy in question has been charged with stalking.