I agree with Tough Love and nasch. You did use a false dichotomy. And now you're using a straw man.
It might well not be in your best interests to fire your top programmer for antagonising only your worst programmer. However if your top programmer antagonises many of your other programmers, including some of your best ones, it could be another story.
I have to respectfully disagree. The patent itself is the motivator to invent better and novel ways of doing things. Without the patent, we would likely not have a great many awesome things we have today. The short(er) time-frame of a patent allows the market to change things after the creator has had his day.
Patents are a motivator for invention, but not the biggest one in most industries (Lopez, 2009, p. 21). (This is a meta-analysis. If I remember right, I found this paper to be an amusing read, because it was commissioned by WIPO, and it seemed apparent that the author really wanted to say something good about patents, but struggled to find anything.) Past research suggests that only pharmaceutical and chemical patents have actually provided us with a large number of inventions that we otherwise wouldn't have (Mansfield, 1986). (Sorry, no link for this one--I just found it mentioned in the above.)
It may intuitively seem like patents ought to provide a net social benefit, but (aside from chemical and pharmaceutical patents) do you really have any reason to believe it?
Driving while on drugs was associated with more deaths in 2015 than driving with alcohol in one's system... marijuana accounted for 35% of positive tests reported
Pot smokers account for lots of driving deaths....
Maybe. However, the report notes:
A drug may be present at low levels without any impairing effects. Some drugs or metabolites may remain in the body for days or weeks, long after any impairment has disappeared. In particular, marijuana metabolites can be detected in the body for weeks after use. (p. 13)
This is a summary of multiple studies that attempt to control for various factors in differing ways. It's unfortunate that alcohol isn't listed separately, but I think the numbers given are suggestive. And while I wouldn't consider an up to 3 fold crash risk "slightly increased", perhaps it's appropriate if alcohol is our standard.
No, 0/0 doesn't produce ANYTHING. You cannot perform the operation. The original statement is correct.
It doesn't need to be a problem, as long as you're willing to allow partially-defined expressions. It's just not useful to do.
As another poster has pointed out, we already accept the positive-or-negative square-root operator as producing a partially-defined expression. If we have A = B^2, then we have B = +-_/A (using ^2 for square and _/ for square root). If A = 4, then we have B = +-_/4, and B can be 2 or -2, so we can have 2 = +-_/4 and -2 = +-_/4. This would be a problem if we insist on +-_/4 being fully defined, since we would conclude 2 = -2, so we have a contradiction. If we allow +-_/4 to be partially defined, though, then can't conclude that 2 = -2, and we don't have a contradiction.
Considering 0 / 0 as a partially-defined expression:
Division is the inverse of multiplication. If we have A = B * C, then we have B = A / C (and C = A / B). If A and C are 0, then we have 0 = B * 0, and B = 0 / 0. B could be any number, so we can have 0 = 0 / 0, and 1 = 0 / 0, and so on. This is fine, as long as we're willing to accept 0 / 0 as partially defined, and don't conclude that 0 = 1. It's just not useful, since it doesn't tell us anything about B (besides the implication that it's some kind of number).
This is different from 1 / 0 (or any other non-zero number divided by 0) which leads to a contradiction even if we allow partially-defined expressions. If we have A = B * C, and try A = 1 and C = 0, we get 1 = B * 0, and B = 1 / 0. But there is no number that satisfies this equation. The question contains an implied contradiction, even if we allow partially-defined expressions.
I didn't intend to claim the article should be assumed to be reliable. I just wasn't sure if your source could be assumed to be reliable either. Perhaps it is reliable, but I don't have enough information to know that.
Adams (2000) Tacking on money laundering charges to white collar crimes: What did congress intend, and what are the courts doing? https://readingroom.law.gsu.ed...
If the archive I've seen is correct, accusation of "mansplaning" was her opening line in the conversation.
The linked article describes her first responses as follows:
Price both replied directly to Deroir, tweeting "thanks for trying to tell me what we do internally, my dude," and retweeted his response with the caption "today in being a female game dev."
I guess there must be some inaccuracy either in the article, or the archive you saw, because they seem to contradict.
The term "mansplaining" is mentioned a little later in the article as follows:
Price's suggestion that Deroir was mansplaining game development -- an area where he does not have the same knowledge or experience -- sparked anger among the ArenaNet community.
There are several comments highly critical of Price's sexist attitude, and I would tend to agree, except that reading the article, I think "mansplaining" might be the reporter's choice of words, rather than Price's.
It doesn't matter when the original thing you did wrong was. When you do something a little bit naughty, but you use international banking systems to do, it might be felony fraud in any of the countries whose banks you used. And when you have a group of people doing something naughty together as a group, and even flying to a foreign country to move money around, yeah, only idiots on the internet care that original thing would have only been a little bit naughty if one person was doing it.
Money laundering charges were intended to prevent people from using transactions to obscure the origin of money obtained through the black-market, such as cash obtained from drug dealing. They were not intended as general tack-on charges to anything, or as a means for prosecutors to convert civil cases into criminal ones.
None of the people whose opinions matter (lawyers, judges, diplomats) care about that, they care about the more-bad parts that were named.
Prosecutors love money-laundering laws, but defence not so much.
Yes, the US is seeking extradition over the transfer of money in the US, not copyright infringement. Of course, the transfer of money is not itself illegal. It is only illegal if there was copyright infringement. However copyright infringement doesn't warrant extradition. Hence the need to seek extradition though tack-on charges instead.
However, to answer the previous poster, yes, I believe the relevant server was in the US (which raises the question of why there was a need for an armed raid in NZ). The electronics that was taken from NZ was personal stuff, such as personal computers, and the security system with video footage of the raid.
Contrary to OP's post, was not "mistakenly posted to a publicly available system (in the sense OP intends it)," it was instead, insofar as this is relevant, posted to a server with atrociously ineffective "security."
I don't know how "security" is actually defined under the relevant law, however I think for something to qualify as security, it ought to require some effort or intent to bypass. Security ought to serve a "notice function". If you can accidentally bypass it without even realising you've done so, I don't think it ought to qualify.
Is there any evidence at all that "chromium isn't stable enough" for overwhelming majority of users?
You could be right about that. I did say stability and performance though, and performance may be the bigger issue. With clock speeds now apparently stagnant, further gains in performance need to be made through parallelism. This is how Chrome gained an advantage over Firefox in performance, but Chrome isn't well placed to make any further gains in this area without risking sacrificing stability, while Firefox is now well placed to do this.
In terms of stability and performance, their aim is to be better. As I understand it, Chrome uses some multithreading to provide parallelism, to make better use of multicore processors and reduce blocking. Multithreaded code, however, poses challenges for stability, while isolating threads in separate processes to improve stability incurs performance overheads. Mozilla has been working on a very ambitious long-term plan to address this by developing a new language (Rust) to allow low-overhead massively multithreaded code to be developed more reliably.
The new code has only recently started replacing the old, so the current release of Firefox is as much an early version of a new browser as a new version of an old browser. Not only that, it is, as far as I know, the first major end-user project to use the new language. Teething problems are to be expected, but in spite of this, it is already (in my opinion) a fairly decent browser. I expect it to improve, and I think it has a good chance of beating Chrome on technical merit.
Whether they can win over hearts and minds, though, is another matter.
As far as the look and feel is concerned, I'm more-or-less inclined to agree with you, although I don't have particularly strong views on it. I do think stability and performance are worthwhile aims, though. I think this is part of what allowed Firefox to compete against MSIE, and it was achieved by rewriting (rather than attempting to iteratively improve) the old Netscape code base. This successful approach is what they are attempting to repeat, with the hope of achieving the same result. In order to follow through on it though, they have to break compatibility with the old Firefox code base. Since they have only recently done this, it is too early to judge what it will allow them to achieve in terms of stability and performance.
We all have our needs. One of the best parts of pre-quantum firefox has been that it could be adapted to serve unique needs of each and every user, thanks to the myriad of very powerful addons that could customize the browser in incredible amount of ways.
With that gone, it's basically worse chromium....
I like Firefox's promise-based API better than Chrome's callback-based one (since it means I can use async functions, and not have to worry about either promises or callbacks). Other than that, this is probably a fair assessment at it stands. However, as I understand it, Firefox's high level of customisability has made it difficult to make major changes to the code base, and the main reason for the break is to make it easier to rewrite Firefox, to compete with Chrome on stability and performance.
I know it's not going to be any consolation to you, or anyone else who depends on extensions that are no longer supported, but my own experience of the new Firefox has been quite positive.
I'm writing a web extension for use in-house at work, with async and await so I don't have to work with promises (or callbacks) explicitly, TypeScript and web-ext-types for type safety, and webextension-polyfill to provide Chrome compatibility (much easier than writing for Chrome directly, and having to use callbacks, I think). For my use case, it's been quite pleasant to work with.
So why does Rust require the programmer to describe intent to an exacting detail, rather than figuring it out on its own? If computers are so very fast at it?
Come now, that's not fair. I said the computer can perform checks faster than the programmer can, not that it can figure out the intent of the program faster than the programmer can.
Also, Rust does absolutely nothing about deadlocks. Its multithreading features were designed by people looking for an appearance of parity with e.g. POSIX threads, while neglecting practical applicability. The same problem exists in various other new languages, such as Java and D; omitting POSIX, they can't reach parity despite replicating the threading portion equivalently.
AFAIK, Rust can guarantee against unsafe memory access, which POSIX threads, per se, can't. AFAIK, you're right that Rust can't guarantee against deadlocks, but then POSIX threads, per se, can't do that either. But then, I think POSIX is kind of lower level anyway, and Rust programs can be made to run on it, or on other systems, so you're kind of comparing apples to... well, not so much oranges, as something that can be made with apples... or alternatively with other fruit... like a fruit pie, or something.
Rust aims for thread safety only through the blunt tool of object lifetime management, but people make it out as though it performs magical compile time checks for deeper threading issues.
It does track object lifetimes, but I believe it also tracks ownership (where an object fits in the data structure), and "borrowing" (which function/thread is editing the object).
Why is it the language's job to make sure your code is somehow "safe"?
Because a computer can perform checks faster and more reliably than a programmer can. My understanding is that Rust has thread safety as one of it's main goals, that this is something that is difficult for programmers to check, and that it's becoming increasingly relevant because multiple cores are replacing increasing clock speeds as a means of increasing computer performance.
Common sense itself is common by definition. You might not think so, given all the things that people claim are common sense. However it is rare that an appeal to common sense refers to something that is actually common sense, because if that thing actually had been common sense, it would have been unlikely for a disagreement to have arisen around it, so there would have been no cause for making an appeal to common sense.
I understand the sentiment, but without the rule of law you probably get the rule of mobsters. We do not yet live in a science-fictional world where coercion is impossible, regardless of the number of arms borne by one side or the other. This might have to wait for a post-scarcity society, if it is even possible then.
To clarify, my post was intended as sarcasm. I was arguing against the idea that the absence of rules equates to freedom.
Slashdot Mirror
It sounds like, on this point, you agree with Tough Love rather than c6gunner.
I'm running with that. But pointing out that, at some point, toxicity may well be detrimental to productivity.
I agree with Tough Love and nasch. You did use a false dichotomy. And now you're using a straw man.
It might well not be in your best interests to fire your top programmer for antagonising only your worst programmer. However if your top programmer antagonises many of your other programmers, including some of your best ones, it could be another story.
Patents are a motivator for invention, but not the biggest one in most industries (Lopez, 2009, p. 21). (This is a meta-analysis. If I remember right, I found this paper to be an amusing read, because it was commissioned by WIPO, and it seemed apparent that the author really wanted to say something good about patents, but struggled to find anything.) Past research suggests that only pharmaceutical and chemical patents have actually provided us with a large number of inventions that we otherwise wouldn't have (Mansfield, 1986). (Sorry, no link for this one--I just found it mentioned in the above.)
It may intuitively seem like patents ought to provide a net social benefit, but (aside from chemical and pharmaceutical patents) do you really have any reason to believe it?
Lopez, Andres (2009) Innovation and appropriability, empirical evidence and research agenda. In WIPO (2009) The Economics of Intellectual Property.
Mansfield, Edwin (1986) Patents and Innovation: An Empirical Study, 32, Mgmt. Science 173.
AFAIK, patents on chemical and pharmaceutical do bring a net benefit to society, but other patents don't.
Bessen, James & Meurer, Michael J. (2008) Patent Failure. Princeton University Press.
Maybe. However, the report notes:
And this table also seems relevant:
This is a summary of multiple studies that attempt to control for various factors in differing ways. It's unfortunate that alcohol isn't listed separately, but I think the numbers given are suggestive. And while I wouldn't consider an up to 3 fold crash risk "slightly increased", perhaps it's appropriate if alcohol is our standard.
It doesn't need to be a problem, as long as you're willing to allow partially-defined expressions. It's just not useful to do.
As another poster has pointed out, we already accept the positive-or-negative square-root operator as producing a partially-defined expression. If we have A = B^2, then we have B = +-_/A (using ^2 for square and _/ for square root). If A = 4, then we have B = +-_/4, and B can be 2 or -2, so we can have 2 = +-_/4 and -2 = +-_/4. This would be a problem if we insist on +-_/4 being fully defined, since we would conclude 2 = -2, so we have a contradiction. If we allow +-_/4 to be partially defined, though, then can't conclude that 2 = -2, and we don't have a contradiction.
Considering 0 / 0 as a partially-defined expression:
Division is the inverse of multiplication. If we have A = B * C, then we have B = A / C (and C = A / B). If A and C are 0, then we have 0 = B * 0, and B = 0 / 0. B could be any number, so we can have 0 = 0 / 0, and 1 = 0 / 0, and so on. This is fine, as long as we're willing to accept 0 / 0 as partially defined, and don't conclude that 0 = 1. It's just not useful, since it doesn't tell us anything about B (besides the implication that it's some kind of number).
This is different from 1 / 0 (or any other non-zero number divided by 0) which leads to a contradiction even if we allow partially-defined expressions. If we have A = B * C, and try A = 1 and C = 0, we get 1 = B * 0, and B = 1 / 0. But there is no number that satisfies this equation. The question contains an implied contradiction, even if we allow partially-defined expressions.
I didn't intend to claim the article should be assumed to be reliable. I just wasn't sure if your source could be assumed to be reliable either. Perhaps it is reliable, but I don't have enough information to know that.
This seems relevant:
Adams (2000) Tacking on money laundering charges to white collar crimes: What did congress intend, and what are the courts doing?
https://readingroom.law.gsu.ed...
The linked article describes her first responses as follows:
I guess there must be some inaccuracy either in the article, or the archive you saw, because they seem to contradict.
The term "mansplaining" is mentioned a little later in the article as follows:
There are several comments highly critical of Price's sexist attitude, and I would tend to agree, except that reading the article, I think "mansplaining" might be the reporter's choice of words, rather than Price's.
Money laundering charges were intended to prevent people from using transactions to obscure the origin of money obtained through the black-market, such as cash obtained from drug dealing. They were not intended as general tack-on charges to anything, or as a means for prosecutors to convert civil cases into criminal ones.
Prosecutors love money-laundering laws, but defence not so much.
Yes, the US is seeking extradition over the transfer of money in the US, not copyright infringement. Of course, the transfer of money is not itself illegal. It is only illegal if there was copyright infringement. However copyright infringement doesn't warrant extradition. Hence the need to seek extradition though tack-on charges instead.
However, to answer the previous poster, yes, I believe the relevant server was in the US (which raises the question of why there was a need for an armed raid in NZ). The electronics that was taken from NZ was personal stuff, such as personal computers, and the security system with video footage of the raid.
I don't know how "security" is actually defined under the relevant law, however I think for something to qualify as security, it ought to require some effort or intent to bypass. Security ought to serve a "notice function". If you can accidentally bypass it without even realising you've done so, I don't think it ought to qualify.
You could be right about that. I did say stability and performance though, and performance may be the bigger issue. With clock speeds now apparently stagnant, further gains in performance need to be made through parallelism. This is how Chrome gained an advantage over Firefox in performance, but Chrome isn't well placed to make any further gains in this area without risking sacrificing stability, while Firefox is now well placed to do this.
In terms of stability and performance, their aim is to be better. As I understand it, Chrome uses some multithreading to provide parallelism, to make better use of multicore processors and reduce blocking. Multithreaded code, however, poses challenges for stability, while isolating threads in separate processes to improve stability incurs performance overheads. Mozilla has been working on a very ambitious long-term plan to address this by developing a new language (Rust) to allow low-overhead massively multithreaded code to be developed more reliably.
The new code has only recently started replacing the old, so the current release of Firefox is as much an early version of a new browser as a new version of an old browser. Not only that, it is, as far as I know, the first major end-user project to use the new language. Teething problems are to be expected, but in spite of this, it is already (in my opinion) a fairly decent browser. I expect it to improve, and I think it has a good chance of beating Chrome on technical merit.
Whether they can win over hearts and minds, though, is another matter.
As far as the look and feel is concerned, I'm more-or-less inclined to agree with you, although I don't have particularly strong views on it. I do think stability and performance are worthwhile aims, though. I think this is part of what allowed Firefox to compete against MSIE, and it was achieved by rewriting (rather than attempting to iteratively improve) the old Netscape code base. This successful approach is what they are attempting to repeat, with the hope of achieving the same result. In order to follow through on it though, they have to break compatibility with the old Firefox code base. Since they have only recently done this, it is too early to judge what it will allow them to achieve in terms of stability and performance.
I like Firefox's promise-based API better than Chrome's callback-based one (since it means I can use async functions, and not have to worry about either promises or callbacks). Other than that, this is probably a fair assessment at it stands. However, as I understand it, Firefox's high level of customisability has made it difficult to make major changes to the code base, and the main reason for the break is to make it easier to rewrite Firefox, to compete with Chrome on stability and performance.
I know it's not going to be any consolation to you, or anyone else who depends on extensions that are no longer supported, but my own experience of the new Firefox has been quite positive.
I'm writing a web extension for use in-house at work, with async and await so I don't have to work with promises (or callbacks) explicitly, TypeScript and web-ext-types for type safety, and webextension-polyfill to provide Chrome compatibility (much easier than writing for Chrome directly, and having to use callbacks, I think). For my use case, it's been quite pleasant to work with.
Come now, that's not fair. I said the computer can perform checks faster than the programmer can, not that it can figure out the intent of the program faster than the programmer can.
AFAIK, Rust can guarantee against unsafe memory access, which POSIX threads, per se, can't. AFAIK, you're right that Rust can't guarantee against deadlocks, but then POSIX threads, per se, can't do that either. But then, I think POSIX is kind of lower level anyway, and Rust programs can be made to run on it, or on other systems, so you're kind of comparing apples to... well, not so much oranges, as something that can be made with apples... or alternatively with other fruit... like a fruit pie, or something.
It does track object lifetimes, but I believe it also tracks ownership (where an object fits in the data structure), and "borrowing" (which function/thread is editing the object).
Because a computer can perform checks faster and more reliably than a programmer can. My understanding is that Rust has thread safety as one of it's main goals, that this is something that is difficult for programmers to check, and that it's becoming increasingly relevant because multiple cores are replacing increasing clock speeds as a means of increasing computer performance.
Common sense itself is common by definition. You might not think so, given all the things that people claim are common sense. However it is rare that an appeal to common sense refers to something that is actually common sense, because if that thing actually had been common sense, it would have been unlikely for a disagreement to have arisen around it, so there would have been no cause for making an appeal to common sense.
Obvious really. It's just common sense.
I didn't have enough attention span to read the summary. Could someone please summarise it?
To clarify, my post was intended as sarcasm. I was arguing against the idea that the absence of rules equates to freedom.