Heh, depending on how you define "fantasy elements", sure, but then the same thing can be said of mainstream fiction, detective novels, and the movie Gravity.:)
In the context of science fiction and fantasy, the term "fantasy elements" generally refers to pure magic and other impossible things; since OP claimed that Gravity lacked fantasy elements, that seemed like a more plausible interpretation of what he meant.
I've read some of what he's written on his blog, and I am more than satisfied that he's a racist, sexist, homophobic dipshit who completely deserves all the opprobrium he receives. What's worse, he's one of those crazy religious fanatics who twists the bible into excuses to hate people, like the Westborough folks. As a human, I find him utterly contemptible.
Nevertheless, if I'd been voting on the Hugos this year, I would have judged his work on its own merit. I still find Orson Scott Card an outstanding writer, despite my (milder) contempt for the man himself. Fortunately, I have many friends who were Hugo voters this year, who are also capable of separating their opinion of the artist from their opinion of the art, and they have uniformly told me that the work didn't deserve a nomination, let alone a win. Maybe it wasn't bad enough to end up below no-award--maybe that happened because of Day's vile on-line persona--but the fact that it didn't win seems to me to be fully justified.
Gravity isn't science fiction. We actually do send people into space, and that kind of disaster could sort of happen.
"Could happen"--but hasn't. That's what makes it science fiction. "Speculative science" is absolutely not a requirement of SF, and "predictions of the future" is basically what it was. It was at least as plausible a prediction as something like Heinlein's "...If This Goes On". And "fantasy elements", in a lot of people's opinions, loosely including mine, are never an element of actual science fiction.
Space exploration and research still falls basically in the domain of science these days, even though it's a lot more of an everyday activity than it once was. Once tickets to space become affordable to the average person, then maybe we can say that a movie like Gravity is no more SFnal than something like The Fast and the Furious. But until then, I think it qualifies, and a whole lot of people seem to agree with me.
Some meta-analysis of the actual study, along with some examination of how the media has generally thoroughly misrepresented the study, is available at Language Log.
Thus Component 1 (23.6% of test variance) was significantly heritable — h2 = 0.538. The symbol h2 is used to denote "narrow-sense heritability", which is the ratio between the variance due to average effects of alleles, and the phenotypic variance as a whole:
$$h^2 = \frac{Var(A)}{Var(P)}$$
In other words, about half of the variance in a PCA component accounting for about a quarter of the variance in test results was accounted for by genetic variation.
Component 3 (10.8% of test variance) was also significantly heritable, with h2 = 0.335. Thus about a third of the variance in a PCA component accounting for about a tenth of the variance in test results was accounted for by genetic variation.
The genetic relationships of components 2 (11.7 of test-score variance) and 4 (8.2% of test-score variance) were not statistically significant.
A quarter plus a tenth of the test results were shown to be related at all (not in whole, but at all) to heritable traits. The grand total overall was just under 16% (a half of a quarter, plus a third of a tenth).
Now, I don't know about you, but I wouldn't describe 16% as "largely". I'd describe 16% as "partly", or "mildly", or "somewhat". But of course, reporters for Nat'l Geo and The Independent and the like aren't big on math.
It's still an interesting and intriguing study, of course, but so grossly misreported that it boggles the mind. We need a better grade of chimpanzee writing science articles for the general public!:D
I always break up code into reasonable sized functions
That's nice if you're working alone, and never have to deal with other people's code, and don't have to fight management tooth-and-nail for any change larger than the bare minimum required to fix a specific problem.
In your non-Python language of choice, how do you tell the difference between an error in indentation and an error in marking the beginning and ending of blocks?
Difference? There is no difference! I don't indent! I mark the beginning and end of blocks, and the code is automatically indented to match. I can, with some difficulty, defeat this mechanism, but I can't think of any reason why I'd want to.
You're free to dislike the way Python handles blocks and white space.
Thank you. Not that I needed your permission, but I shall indeed continue to consider it an idiotic design.
But if it actually substantially affects your productivity, you're simply not a very good programmer, because it's not a big deal in practice.
Agreed. However the fact that it doesn't noticably harm my productivity doesn't mean it's a good feature.
In any case, we're discussing its potential use as a teaching language here, and people who are just starting to learn to program are, pretty much by definition, not good programers. So its impact on not-good-programmers is still very relevant.
Except there are people who survived crashes at much higher speeds.
There are people who have survived jumping out of "perfectly good" airplanes without a functioning parachute. Doesn't mean you should take up skydiving-without-a-parachute as a hobby.:)
There's a reason cases like you mention make the news: surviving a crash at those speeds is an impressive and newsworthy feat. (The reason this case made the news was not the fact that the driver died, but the fact that a Tesla was involved. Otherwise, it seems like a pretty unremarkable story.)
Richard Hammond of Top Gear UK fame survived a crash at 288 mph
And I bet he was buckled in. Remaining in the vehicle during a high-speed crash greatly increases your chances of survival. Exiting a vehicle at 100+ mph is generally contraindicated! (Tip for future reference.);)
Have you ever been fooled by incorrect indentation that didn't compile the way it looked?
Nope. My editor takes care of indentation for me, in every common language except Python, and when I have to deal with a batch of code written by someone else, I run it through indent(1) first. So, in fact, it's just the opposite: when the indentation doesn't match what I expect, I know there's an actual problem in the code!
With Python, on the other hand, I'm actually more likely to have an error in the indenting, because there's no easy way to see how many blocks I'm terminating when I outdent by an arbitrary amount. Which is a real PITA when you're refactoring.
Of course, things may be different if you're using crappy tools. But professionals shouldn't be using crappy tools.
Brackets, begin..end, and semicolons are crutches for compiler writers not programmers.
No, they're tools to make my job easier. Whatever the historical reason for them may be, they benefit the programmer! They make me more productive.
Now, I'll grant that Python is a remarkably good language despite its horrible flaw of relying on indentation. And many of its good features also make me more productive. But that doesn't mean that relying on the indentation isn't a horrible flaw.
If the answer is humans need a full gee, then we might as well just resign ourselves to limiting our trips into the solar system to quick jaunts and robotic explorers.
Disagree. Large-scale habitats/SPS/O'Neill Colonies have always been the best option. No huge gravity wells to deal with, since rotation provides your G's, and, while they are extraordinarily expensive, they cost nothing compared to a full-scale terraforming effort, and can provide a shirt-sleeve environment in basically no time flat. The one remaining big knock on them was the issue of radiation shielding, and now, that may be solved.
non-distributed version control systems seem so much simpler
I find quite the opposite. The simplest case is one user, and a "distributed" VCS is clearly the easiest option in that case--no central repository needed, no environment variables to set, or separate paths to worry about. Just say "init", and you're off and running. (At least with Mercurial or Git, the two DVCSes I have experience with.)
With more than one user, it's slightly more complicated, but not enough to worry about. It all boils down to the distinction between "save this change" and "share my changes with my co-workers". Having those as separate commands really isn't that confusing, and once you're used to it (which should not take long), you'll have a hard time remembering how you lived without it! And that really is the entire difference, fundamentally, between distributed and non-distributed VCSes.
(Most of the things that are great about Git are unrelated to the distributed/non-distributed aspect, or at best tangential to it. For me, the big wins of either Git or Mercurial over, say, Subversion, are how much better/faster/easier/more powerful branching is, which doesn't really have to do with being distributed or not, and how much faster the whole thing is, overall, without all those network round-trips, which does.)
I started out somewhat skeptical, like you, but after my first pilot project, using Mercurial, I was a complete convert! YMMV but it Works For Me(tm)!:)
That's because TFS is the usual slashdot idiocy, and TFA is simply bad reporting. This report tells quite a different story:
"As Judge Beeler explains, companies can choose not only whether to include the Like button in the first place, but also to specify what information the button should relay to Facebook through cookies. In the case of Hulu, the presence of the button conveyed not only basic browser information, but also details about the user’s “watch page” — a personal page that every Hulu user has."
...and...
"The judge noted that the information transfer was not restricted to occasions when a Hulu user “Liked” a video, but rather every time a user watched a video."
So yeah, I'd say it sounds like a lot more than I'd expect was being shared.
A Facebook "like" button is different than a local-to-the-site "like" button. It only works if you have a FB account, and uses the clearly recognizable FB logo. Anyone who uses FB recognizes the button, and expects it to work the same on all sorts of different sites.
The apparent problem here (according to what I've heard) is that the FB "like" button on Hulu didn't just share your like of the movie with your FB friends; it shared your entire viewing history! If that's actually true, then I definitely have to side with the plaintiff on this one. That's not what anyone would normally expect. But if it just shared the fact that he like that movie, then it's exactly what he should have expected, and he should lose the case big time!
Your friend is ignorant. Goto is a powerful-but-dangerous tool that should be used with extreme caution, if at all. However, to say that it's the mark of a bad programmer is insanely ignorant. It is often the mark of a bad programmer, but it can also be the mark of an exceptionally good one. The key is in knowing when you use it and when not to.
If your friend thinks he's a better programmer than Donald Knuth, then he's almost certainly suffering from the Dunning-Kruger effect. If he hasn't read Knuth's "Structured Programming with Gotos" (a direct response to Wirth's original "Goto Considered Harmful" paper), then he's not qualified to opine on the subject.
That said, probably 90% of the time (if not more), your friend will be correct. In the last over-a-decade, I've used goto once. And that lone case was after nearly a dozen attempts to find a way to around it that wasn't worse. I don't like gotos, and feel a little dirty that I ended up using it even that once. (If I'd been working in C++ or Java or Python, I would have used an exception, but I was writing in C.) A goto usually makes your code more difficult to read, and more fragile, and you should never use one unless you can prove the alternatives are worse. Which probably takes a lot more expertise than it sounds like you currently have, so avoiding them completely is probably the best plan for now. For you.
Not really. There was no particular reason to think this was impossible. We just didn't have any evidence it was possible.
Any complications to other theories?
Not to any useful theories. Theories like the Electric Universe have one more thing added to the list of things they can't explain, but that's no surprise.:)
That's a fair point, and if he really wanted to sue Mozilla, I'd expect that would be his most plausible angle to try to exploit. However, A) I don't think he wants to sue Mozilla, which makes the whole question somewhat moot, and B) he's still primarily a techy, not a professional CEO, which might well have made a more tech-oriented position attractive to him if the issue had actually come up before he resigned.
If you support trying to hurt (a set of) people, you shouldn't be surprised if those people (and their friends) start to dislike you and act accordingly.
What alternative do you offer? Forcing people to buy bread from the bigotted baker at gunpoint? Or forcing people to keep using Mozilla even though it's represented by a man who tried to take away their rights?
It would be nice if the world could be broken down into nice, neat piles of black and white, good and evil, but the real world is inevitably more complicated than that, and pretending otherwise is not useful or productive.
I notice you carefully avoided answering my original question, though. Is that because you didn't understand it, or because you couldn't?
If it was a serious offer, and the company could show that was the position he was best suited for, then no. Otherwise, it would clearly be a ruse to try to force him out, and the law actually takes such things into account. (Which makes your suggestion a straw man.)
A serious offer, for a job that would suit his skills would easily defeat any claims of unlawful termination. A insult obviously intended to pressure him into quitting might not. If you can't figure out the difference between the two, then I recommend you stay away from any job that involves interactions with the law, or the public.
The chairman of the board went on the record saying "It's clear that Brendan cannot lead Mozilla in this setting".
The key word there is "lead". Show me where it said he should leave the company, rather than merely take a different role within the company, and I might concede you have a point. But if mere employment is equivalent to leading, then my employers are going to be in for some big surprises tomorrow!:)
Duh, by attempting to take away the rights of people. (Same-sex marriage was legal in California at the time.) I don't know how much more obvious it could be. The fact that he has the right to say it doesn't mean he wasn't attempting to limit the rights of others.
Freedom of speech does not mean freedom from all consequences. If your local baker were campaigning to repeal the 19th amendment, would you argue that women (or people who like women) who refuse to buy his products are infringing his rights somehow? If so, you have one of the stupidest definitions of "I'll defend to the death your right to say it" I've ever heard.
Did you even read the summery: "'It's clear that Brendan cannot lead Mozilla in this setting,' Baker was quoted as saying."
Did you even read it? It says "lead", not "work for". To win a suit, he'd have to prove that no other openings would have been available to him in the company. And this is a man who was valued primarily for his technical skills (as the developer of Javascript), and who was promoted from within, so I think that would be quite a stretch.
Slashdot Mirror
Heh, depending on how you define "fantasy elements", sure, but then the same thing can be said of mainstream fiction, detective novels, and the movie Gravity. :)
In the context of science fiction and fantasy, the term "fantasy elements" generally refers to pure magic and other impossible things; since OP claimed that Gravity lacked fantasy elements, that seemed like a more plausible interpretation of what he meant.
I've read some of what he's written on his blog, and I am more than satisfied that he's a racist, sexist, homophobic dipshit who completely deserves all the opprobrium he receives. What's worse, he's one of those crazy religious fanatics who twists the bible into excuses to hate people, like the Westborough folks. As a human, I find him utterly contemptible.
Nevertheless, if I'd been voting on the Hugos this year, I would have judged his work on its own merit. I still find Orson Scott Card an outstanding writer, despite my (milder) contempt for the man himself. Fortunately, I have many friends who were Hugo voters this year, who are also capable of separating their opinion of the artist from their opinion of the art, and they have uniformly told me that the work didn't deserve a nomination, let alone a win. Maybe it wasn't bad enough to end up below no-award--maybe that happened because of Day's vile on-line persona--but the fact that it didn't win seems to me to be fully justified.
Gravity isn't science fiction. We actually do send people into space, and that kind of disaster could sort of happen.
"Could happen"--but hasn't. That's what makes it science fiction. "Speculative science" is absolutely not a requirement of SF, and "predictions of the future" is basically what it was. It was at least as plausible a prediction as something like Heinlein's "...If This Goes On". And "fantasy elements", in a lot of people's opinions, loosely including mine, are never an element of actual science fiction.
Space exploration and research still falls basically in the domain of science these days, even though it's a lot more of an everyday activity than it once was. Once tickets to space become affordable to the average person, then maybe we can say that a movie like Gravity is no more SFnal than something like The Fast and the Furious. But until then, I think it qualifies, and a whole lot of people seem to agree with me.
Some meta-analysis of the actual study, along with some examination of how the media has generally thoroughly misrepresented the study, is available at Language Log.
Thus Component 1 (23.6% of test variance) was significantly heritable — h2 = 0.538. The symbol h2 is used to denote "narrow-sense heritability", which is the ratio between the variance due to average effects of alleles, and the phenotypic variance as a whole:
$$h^2 = \frac{Var(A)}{Var(P)}$$
In other words, about half of the variance in a PCA component accounting for about a quarter of the variance in test results was accounted for by genetic variation.
Component 3 (10.8% of test variance) was also significantly heritable, with h2 = 0.335. Thus about a third of the variance in a PCA component accounting for about a tenth of the variance in test results was accounted for by genetic variation.
The genetic relationships of components 2 (11.7 of test-score variance) and 4 (8.2% of test-score variance) were not statistically significant.
A quarter plus a tenth of the test results were shown to be related at all (not in whole, but at all) to heritable traits. The grand total overall was just under 16% (a half of a quarter, plus a third of a tenth).
Now, I don't know about you, but I wouldn't describe 16% as "largely". I'd describe 16% as "partly", or "mildly", or "somewhat". But of course, reporters for Nat'l Geo and The Independent and the like aren't big on math.
It's still an interesting and intriguing study, of course, but so grossly misreported that it boggles the mind. We need a better grade of chimpanzee writing science articles for the general public! :D
I always break up code into reasonable sized functions
That's nice if you're working alone, and never have to deal with other people's code, and don't have to fight management tooth-and-nail for any change larger than the bare minimum required to fix a specific problem.
In your non-Python language of choice, how do you tell the difference between an error in indentation and an error in marking the beginning and ending of blocks?
Difference? There is no difference! I don't indent! I mark the beginning and end of blocks, and the code is automatically indented to match. I can, with some difficulty, defeat this mechanism, but I can't think of any reason why I'd want to.
You're free to dislike the way Python handles blocks and white space.
Thank you. Not that I needed your permission, but I shall indeed continue to consider it an idiotic design.
But if it actually substantially affects your productivity, you're simply not a very good programmer, because it's not a big deal in practice.
Agreed. However the fact that it doesn't noticably harm my productivity doesn't mean it's a good feature.
In any case, we're discussing its potential use as a teaching language here, and people who are just starting to learn to program are, pretty much by definition, not good programers. So its impact on not-good-programmers is still very relevant.
Except there are people who survived crashes at much higher speeds.
There are people who have survived jumping out of "perfectly good" airplanes without a functioning parachute. Doesn't mean you should take up skydiving-without-a-parachute as a hobby. :)
There's a reason cases like you mention make the news: surviving a crash at those speeds is an impressive and newsworthy feat. (The reason this case made the news was not the fact that the driver died, but the fact that a Tesla was involved. Otherwise, it seems like a pretty unremarkable story.)
Richard Hammond of Top Gear UK fame survived a crash at 288 mph
And I bet he was buckled in. Remaining in the vehicle during a high-speed crash greatly increases your chances of survival. Exiting a vehicle at 100+ mph is generally contraindicated! (Tip for future reference.) ;)
Have you ever been fooled by incorrect indentation that didn't compile the way it looked?
Nope. My editor takes care of indentation for me, in every common language except Python, and when I have to deal with a batch of code written by someone else, I run it through indent(1) first. So, in fact, it's just the opposite: when the indentation doesn't match what I expect, I know there's an actual problem in the code!
With Python, on the other hand, I'm actually more likely to have an error in the indenting, because there's no easy way to see how many blocks I'm terminating when I outdent by an arbitrary amount. Which is a real PITA when you're refactoring.
Of course, things may be different if you're using crappy tools. But professionals shouldn't be using crappy tools.
Brackets, begin..end, and semicolons are crutches for compiler writers not programmers.
No, they're tools to make my job easier. Whatever the historical reason for them may be, they benefit the programmer! They make me more productive.
Now, I'll grant that Python is a remarkably good language despite its horrible flaw of relying on indentation. And many of its good features also make me more productive. But that doesn't mean that relying on the indentation isn't a horrible flaw.
If the answer is humans need a full gee, then we might as well just resign ourselves to limiting our trips into the solar system to quick jaunts and robotic explorers.
Disagree. Large-scale habitats/SPS/O'Neill Colonies have always been the best option. No huge gravity wells to deal with, since rotation provides your G's, and, while they are extraordinarily expensive, they cost nothing compared to a full-scale terraforming effort, and can provide a shirt-sleeve environment in basically no time flat. The one remaining big knock on them was the issue of radiation shielding, and now, that may be solved.
Yup. Knotweed is fairly common in the area, but there's none in my back yard.
Blackberries can be controlled
Indeed! In our back yard, they are losing the battle against the ivy and bamboo! :)
free to use unless you intend to kill people.
Would violate clause six of the Open Source Definition (and the Debian Free Software Guidelines): No discrimination against fields of endeavor.
non-distributed version control systems seem so much simpler
I find quite the opposite. The simplest case is one user, and a "distributed" VCS is clearly the easiest option in that case--no central repository needed, no environment variables to set, or separate paths to worry about. Just say "init", and you're off and running. (At least with Mercurial or Git, the two DVCSes I have experience with.)
With more than one user, it's slightly more complicated, but not enough to worry about. It all boils down to the distinction between "save this change" and "share my changes with my co-workers". Having those as separate commands really isn't that confusing, and once you're used to it (which should not take long), you'll have a hard time remembering how you lived without it! And that really is the entire difference, fundamentally, between distributed and non-distributed VCSes.
(Most of the things that are great about Git are unrelated to the distributed/non-distributed aspect, or at best tangential to it. For me, the big wins of either Git or Mercurial over, say, Subversion, are how much better/faster/easier/more powerful branching is, which doesn't really have to do with being distributed or not, and how much faster the whole thing is, overall, without all those network round-trips, which does.)
I started out somewhat skeptical, like you, but after my first pilot project, using Mercurial, I was a complete convert! YMMV but it Works For Me(tm)! :)
That's because TFS is the usual slashdot idiocy, and TFA is simply bad reporting. This report tells quite a different story:
"As Judge Beeler explains, companies can choose not only whether to include the Like button in the first place, but also to specify what information the button should relay to Facebook through cookies. In the case of Hulu, the presence of the button conveyed not only basic browser information, but also details about the user’s “watch page” — a personal page that every Hulu user has."
...and...
"The judge noted that the information transfer was not restricted to occasions when a Hulu user “Liked” a video, but rather every time a user watched a video."
So yeah, I'd say it sounds like a lot more than I'd expect was being shared.
A Facebook "like" button is different than a local-to-the-site "like" button. It only works if you have a FB account, and uses the clearly recognizable FB logo. Anyone who uses FB recognizes the button, and expects it to work the same on all sorts of different sites.
The apparent problem here (according to what I've heard) is that the FB "like" button on Hulu didn't just share your like of the movie with your FB friends; it shared your entire viewing history! If that's actually true, then I definitely have to side with the plaintiff on this one. That's not what anyone would normally expect. But if it just shared the fact that he like that movie, then it's exactly what he should have expected, and he should lose the case big time!
Your friend is ignorant. Goto is a powerful-but-dangerous tool that should be used with extreme caution, if at all. However, to say that it's the mark of a bad programmer is insanely ignorant. It is often the mark of a bad programmer, but it can also be the mark of an exceptionally good one. The key is in knowing when you use it and when not to.
If your friend thinks he's a better programmer than Donald Knuth, then he's almost certainly suffering from the Dunning-Kruger effect. If he hasn't read Knuth's "Structured Programming with Gotos" (a direct response to Wirth's original "Goto Considered Harmful" paper), then he's not qualified to opine on the subject.
That said, probably 90% of the time (if not more), your friend will be correct. In the last over-a-decade, I've used goto once. And that lone case was after nearly a dozen attempts to find a way to around it that wasn't worse. I don't like gotos, and feel a little dirty that I ended up using it even that once. (If I'd been working in C++ or Java or Python, I would have used an exception, but I was writing in C.) A goto usually makes your code more difficult to read, and more fragile, and you should never use one unless you can prove the alternatives are worse. Which probably takes a lot more expertise than it sounds like you currently have, so avoiding them completely is probably the best plan for now. For you.
what is the consequence of this discovery?
Some idle speculation has finally been confirmed.
Will existing theories be changed (or validated)?
Not really. There was no particular reason to think this was impossible. We just didn't have any evidence it was possible.
Any complications to other theories?
Not to any useful theories. Theories like the Electric Universe have one more thing added to the list of things they can't explain, but that's no surprise. :)
That's a fair point, and if he really wanted to sue Mozilla, I'd expect that would be his most plausible angle to try to exploit. However, A) I don't think he wants to sue Mozilla, which makes the whole question somewhat moot, and B) he's still primarily a techy, not a professional CEO, which might well have made a more tech-oriented position attractive to him if the issue had actually come up before he resigned.
If you support trying to hurt (a set of) people, you shouldn't be surprised if those people (and their friends) start to dislike you and act accordingly.
What alternative do you offer? Forcing people to buy bread from the bigotted baker at gunpoint? Or forcing people to keep using Mozilla even though it's represented by a man who tried to take away their rights?
It would be nice if the world could be broken down into nice, neat piles of black and white, good and evil, but the real world is inevitably more complicated than that, and pretending otherwise is not useful or productive.
I notice you carefully avoided answering my original question, though. Is that because you didn't understand it, or because you couldn't?
If it was a serious offer, and the company could show that was the position he was best suited for, then no. Otherwise, it would clearly be a ruse to try to force him out, and the law actually takes such things into account. (Which makes your suggestion a straw man.)
A serious offer, for a job that would suit his skills would easily defeat any claims of unlawful termination. A insult obviously intended to pressure him into quitting might not. If you can't figure out the difference between the two, then I recommend you stay away from any job that involves interactions with the law, or the public.
The chairman of the board went on the record saying "It's clear that Brendan cannot lead Mozilla in this setting".
The key word there is "lead". Show me where it said he should leave the company, rather than merely take a different role within the company, and I might concede you have a point. But if mere employment is equivalent to leading, then my employers are going to be in for some big surprises tomorrow! :)
How did he attempt to limit the rights of others?
Duh, by attempting to take away the rights of people. (Same-sex marriage was legal in California at the time.) I don't know how much more obvious it could be. The fact that he has the right to say it doesn't mean he wasn't attempting to limit the rights of others.
Freedom of speech does not mean freedom from all consequences. If your local baker were campaigning to repeal the 19th amendment, would you argue that women (or people who like women) who refuse to buy his products are infringing his rights somehow? If so, you have one of the stupidest definitions of "I'll defend to the death your right to say it" I've ever heard.
Did you even read the summery: "'It's clear that Brendan cannot lead Mozilla in this setting,' Baker was quoted as saying."
Did you even read it? It says "lead", not "work for". To win a suit, he'd have to prove that no other openings would have been available to him in the company. And this is a man who was valued primarily for his technical skills (as the developer of Javascript), and who was promoted from within, so I think that would be quite a stretch.
Or even just the headline of TFA (if the A itself is too much to handle):
"Japan accepts court ban on Antarctic whaling"
(Emphasis mine.)