Predicting the weather and predicting climate change trends are two different things.
I can predict with high confidence that December 25 will be colder than June 25 (where I live). I can't say with any certainty between the 25th and 26th of the same month; it's pretty much a crapshoot.
I often agree with that attitude in many slashdot discussions, but there is a difference here. Somebody else's decision on what kind of coffee maker to buy has no influence on the value of the different kinds of coffee makers.
Social networking has a strong network effect, fairly obviously, and there's an upper limit to how many different social networks a person will join and maintain (and how they will split their time between them).
If you want to have a good social networking service, it behooves you to convince people of the same criteria you used in choosing which social networks you will not join.
Research doesn't work like Sid Meier's Civilization. You don't know what you're going to get before you try it, and not finding something new when you look in a new place is news.
The GGP said when the PS3 came out, at which point the MSRP was $500 and $600 in the US. The $700 to $800 looks familiar to me in post-tax Canadian dollars (at the time cheaper than US dollars).
I think you either didn't get the PS3 when it came out, or got a pretty amazing deal.
That's a sufficient (but not necessary) condition to having a "friendly" government, if we make the reasonable assumption that when afidel said friendly he meant friendly to the US.
The credit card companies are actually giving me money.
I get 1% cashback on my purchases, have to pay $25 / year for the credit card, but I put recurring bills totallying well over $2500 per month on the credit card, so the $25 is paid easily. I pay everything within the grace period.
After that, there's the subtle time-value effect. Essentially the billing cycle plus grace period provide me with what is essentially extra wealth to invest. It's a trivial trickle amount and not worth a lot of hassle or anything, but being able to make big ticket purchases by credit card and then move the money around in the bank all at once at one time in the month is hassle removed.
If you can't afford a credit card, don't get a credit card. If you can afford to pay it off in full every month, you're foolish not to (unless the terms are far worse than the ones I have). Yes, you could lose your job -- but if you can afford a credit card you can afford to have savings greater than the credit limit to instantly eliminate the credit card debt when the need arises. If you lack the self-control to not overspend on a credit card but somehow have the self-control to not get a credit card, then, yeah, don't get one -- but I just can't comprehend that sort of lack of self-control.
I don't understand what people mean by free will when they say this.
I can't the contradiction between predicting something, and free will. Put another way, I don't see random will as any freer than will based on past events. And those are the two choices (obviously there is a gradient between them).
I can see the contradiction if you add some omnipotent and omniscient creator entity as the one who granted free will -- that's a contradiction because that deity set up the initial conditions and knows the ultimate result. But I also see a contradiction between truly unpredictable events and omniscience, so I think something has to give there anyway.
Baseball teams are collections of people. People also have different affinity for math.
Therefore the New York Yankees are better at math than the Baltimore Orioles.
The logic breaks the same way. Just because race is caused by genes, and intelligence is influenced by genes, does not mean race influences intelligence.
And American, in the most common dialects of English, as spoken in Canada, the United States, the UK, Australia, New Zealand, India, and other places, means a citizen or expatriate of the United States of America.
And anyway, the GP has said specifically:
"Its why so much manufacturing has left the country. In in part why American is sliding from prominence all the while the pay divide has never been larger."
It's 100% clear he was talking about the US. There's no reasonable question about that.
It won't be outdated within a few months. It was released almost 2 years ago and won't be replaced until... well the summary says "end of the year" but it links to something that Microsoft already repudiated. There isn't even a Beta yet as far as I know so I'm skeptical.
I think people have different ideas of what code reviews are. I think it's strange that we're talking about working with computers and everybody is assuming we're doing a face to face meeting with a single projected image.*
In my experience, people basically give me a source code change pack. I get around to looking at the diff when I get the time -- usually within the same day, next business day at latest. I read it myself, make my comments, ask questions, raise objections, and tell them I'm done with the current version. Then, when they get around to it, they send me a new change pack and I take a diff between the changes. Usually the second round is much quicker unless there was a major problem in the first round. Eventually we converge, and the final change is committed. Often for small changes I have no issues and it just goes in the first time. Big changes usually require the second round, occasionally three, very rarely more.
In some cases another reviewer or other reviewers will receive the same packs and do the same thing in parallel -- usually if the change crosses several components with different people familiar with each area. Each reviewer will probably focus on their own area and only make more cursory passes over the parts the other reviewer covers.
* Mind you, we do the projector thing where I work after we release a beta / release candidate, to increase the chances that the next one will be the last. We also do this when we're going to distribute a security patch. In both cases, the projector code review happens only after the more typical code review.
You are way better off entering feedback from actual customers, testers and UI designers, into an issue tracking system, prioritizing the issues, and working them down in order or priority.
By the time your customers are telling you your code is crap, a fix is usually several orders of magnitude more difficult -- and it's already burned your customer! I'm curious what sort of software you write that gives you this opinion -- maybe you ship broadly on a daily basis?
Testers are a valid way to find bugs, but they essentially work on a black box (if they aren't, then they are code reviewers...), which can make it difficult to see certain classes of problems.
As for UI designers, they are pretty much orthogonal to the concept of code reviews.
Code reviews short-circuit the process by ignoring the actual performance of the software
If your code reviews ignore the actual performance of the software, you're doing poor code reviews. It's almost never a good idea to do something poorly; the question of whether code reviews should be used should be read as, should decent code reviews be used. Of course you could argue that decent code reviews are impossible, but you don't seem to be arguing that.
instead using the quality of the source code as the measure of correctness.
The quality of the source code has a very obvious relationship to maintainability. Security is also something that just can't be put off until a user finds it. I can see your argument about robustness (crashes and hangs), that code reviews prioritize the issues you can see whether or not they are common issues -- but really this is the time when fixing them is easiest.
See, priority shouldn't just be about user impact of each bug. It should be user impact divided by the effort required to fix it -- this allows you to give the greatest user impact in aggregate per unit time. But of course, that's difficult to measure.
At the one extreme, bugs from users are prioritized by user impact alone because before investigation you don't even know how much effort is required to fix it (you can figure that out by sinking some time into investigating it).
Code reviews are at the opposite extreme -- it's prioritizing what's easy to fix when it's easiest to fix it, shrinking the denominator. However the user impact is somewhat hypothetical at this point. That said, you can often figure out that something is obviously going to be a frequent problem, eg. a narrow race condition that leads to heap corruption will be a pain in the ass to track down, probably relatively low hitting, with relatively high consequences including security problems. Similarly, a flaw in how text is localized will effect every customer who speaks languages A, B, C, & D.
Users don't care about the correctness of your source code as gauged by comparison to a specification.
You're talking about UI design again, it looks like. That's not the main use case for code reviews. Unless you're talking about a spec as in W3C or OpenDocument or something, in which case, your customers most definitely care.
I'm really curious about this. Could you describe an example? I've never seen the code quality go down objectively after a code review -- most objections I hear are that it's not cost-effective enough.
Subjectively, a cross-department change might be subject to differing coding standards, which might make person from organization A think he's making his code crappier to fit the ideas of organization B (where he's committing his code), because, I dunno, maybe organization B favours "goto cleanup" while organization uses a classic triangle error handling pattern. But from the perspective of the maintainers that's still a victory for consistency.
If the break is subtle and isn't detected, you could have a major system overhaul on your hands. This is particularly and tragically true of software where security is an issue.
To give an idea where I'm coming from, most of my experience is in very large pieces of widely-deployed systems software, where performance and security are both critical. These rules may well not apply if you're working on small to medium projects, or projects only for internal use in a company where all the users already have full read/write access.
I'm going to throw out a couple rules:
1. If you're not code reviewing all of your security-related code, you're not writing secure code. 2. All code is security-related until proven otherwise.
The same goes for maintainability, by the way. Only fixing things when they break and not looking at the things everybody else is doing is an almost certain way of propagating redundant slightly incompatible systems and creating a spaghetti dependency graph in the long run, at least for large software projects. Eventually you descend into a place where the product is almost always broken. To some extent, these things happen anyway with code reviews; they are just a tool to reduce the spread of the problem and even turn it back at times.
The "worse is better" mentality can work for other areas, notably performance. Developers do love to do premature optimizations at times. Even then I'd recommend at least one other person spare a thought of the high-level impact of nontrivial changes so nobody accidentally misses a fundamental flaw.
Your last sentence I actually agree with. That's why you'd do code reviews. Once the "good enough" code is in there, you'll have trouble scraping it out until it's too late. Until it's in there, it doesn't work. If you're going to take the regression risk of making a change, you might as well make the right change. Otherwise, you run that risk again when you fix the originally broken code.
"For someone else to go through all the code to the point that they understand all of it, they have to invest at least as much time as the coder."
I don't see why that would be true.
First off, if it's for a bugfix, you're completely glossing over the time spent identifying the root cause, design, & best fix. You're also forgetting the first-stage testing that the coder did themselves.
Second, if the code is well-designed and structured (and doesn't have a damn good reason to be obfuscated, eg. some hand-optimized assembly sequence), then it should be much easier to read than it ever was to write.
A book tends to take much longer to write than it does to read, even if you're the editor. A television show takes longer to film than to watch and critique.
I have to pull the cellphone out of my pocket and turn it on to tell the time. My cellphone runs out of batteries a nontrivial amount of times when I'm out. It's often doing something else that I don't want to lose. I have to frequently charge my cellphone during which time, if I stray from the cellphone, I don't have its timekeeping abilities. And I don't carry my cellphone 100% of the time, nor do I want to.
A watch has nearly perfect convenience for my purposes whereas using my cellphone is a bag of compromises.
Has the time spent goofing off in a day / blowing off steam / etc. changed signficantly? I didn't live during this time so I don't actually have personal experience, but I suspect it's about the same for the same sort of job. Now, different job types might have had different proportions of time totally used up by things that aren't directly related to getting shit done, but that comes back to the difference between the 60s standard of living and that of today.
Not if you want security updates. That's the crux of the issue. Mozilla's old model continued providing security updates for some time on an otherwise-stable platform. Mozilla's new model does not -- all or nothing. You want to not be hacked by the hot new exploit, then you have to deal with the new interface changes they made, like it or not. And Asa specifically promised that would be the case.
I get not locking down knowledge with paywalls and patents, although patents are a bit funny because the whole point of functional patents is to encourage making knowledge freely available, via the mechanism of legally-enforced limited exclusivity on products. But I don't see why it's a problem to sell stuff enabled by new knowledge?
You can't just extend the timescale like that. The mechanics of almost everything we make have a peak beyond which you lose efficiency. Via time-honoured car analogy: find the velocity of peak efficiency of your car. Say 70kph. Is it more efficient to travel to your destination, which is 70km, and which you arrive at 1 hour later, driving at a constant 70kph, or in fits and starts of 140kph and 0kph (engine completely off, not even idling)? Okay, well, what if you took two hours and then traveled at 70km for the first hour and idled at the end? Scaling out time doesn't make a reasonable analogy.
The A/C is basically going to take a constant amount of time to go from the non-A/C temperature to the steady-state A/C temperature (assuming a constant outdoor temperature for simplicity), and during that time it's running less efficiently because the increasing temperature differentials by a non-infinitesimal amount is not a reversible process, so even the idealised process is inherently inefficient. Furthermore, it's a machine, not an idealism, and most machines tend to be less efficient when working at max capacity. The more often you turn it on and off, the more time in aggregate is being spent in this less efficient state. On the flip side, of course, you're not using any energy at all when it's off, so more time is being spent in a state of ultimate efficiency as well.
Where the optimal point is, I don't know exactly and it certainly depends on the characteristics of your air conditioning, your building, outside temperature, goal temperature inside, time spans you need to reach this goal temperature, tolerances, etc. I fully expect that 6 hours without air conditioning will outweigh a relatively short period of initial cooling.
How is that doublethink? You have a right to vote. You don't have a right to do any of the other things. Also, you're the only person to use the term "unfair"; that never even entered into it. The term is poll tax, and only showing ID to vote is a poll tax.
I kind of think it does make sense to need ID for voting, but then you should get free ID.
Slashdot Mirror
Predicting the weather and predicting climate change trends are two different things.
I can predict with high confidence that December 25 will be colder than June 25 (where I live). I can't say with any certainty between the 25th and 26th of the same month; it's pretty much a crapshoot.
I often agree with that attitude in many slashdot discussions, but there is a difference here. Somebody else's decision on what kind of coffee maker to buy has no influence on the value of the different kinds of coffee makers.
Social networking has a strong network effect, fairly obviously, and there's an upper limit to how many different social networks a person will join and maintain (and how they will split their time between them).
If you want to have a good social networking service, it behooves you to convince people of the same criteria you used in choosing which social networks you will not join.
Research doesn't work like Sid Meier's Civilization. You don't know what you're going to get before you try it, and not finding something new when you look in a new place is news.
The GGP said when the PS3 came out, at which point the MSRP was $500 and $600 in the US. The $700 to $800 looks familiar to me in post-tax Canadian dollars (at the time cheaper than US dollars).
I think you either didn't get the PS3 when it came out, or got a pretty amazing deal.
That's a sufficient (but not necessary) condition to having a "friendly" government, if we make the reasonable assumption that when afidel said friendly he meant friendly to the US.
The credit card companies are actually giving me money.
I get 1% cashback on my purchases, have to pay $25 / year for the credit card, but I put recurring bills totallying well over $2500 per month on the credit card, so the $25 is paid easily. I pay everything within the grace period.
After that, there's the subtle time-value effect. Essentially the billing cycle plus grace period provide me with what is essentially extra wealth to invest. It's a trivial trickle amount and not worth a lot of hassle or anything, but being able to make big ticket purchases by credit card and then move the money around in the bank all at once at one time in the month is hassle removed.
If you can't afford a credit card, don't get a credit card. If you can afford to pay it off in full every month, you're foolish not to (unless the terms are far worse than the ones I have). Yes, you could lose your job -- but if you can afford a credit card you can afford to have savings greater than the credit limit to instantly eliminate the credit card debt when the need arises. If you lack the self-control to not overspend on a credit card but somehow have the self-control to not get a credit card, then, yeah, don't get one -- but I just can't comprehend that sort of lack of self-control.
I don't understand what people mean by free will when they say this.
I can't the contradiction between predicting something, and free will. Put another way, I don't see random will as any freer than will based on past events. And those are the two choices (obviously there is a gradient between them).
I can see the contradiction if you add some omnipotent and omniscient creator entity as the one who granted free will -- that's a contradiction because that deity set up the initial conditions and knows the ultimate result. But I also see a contradiction between truly unpredictable events and omniscience, so I think something has to give there anyway.
Baseball teams are collections of people. People also have different affinity for math.
Therefore the New York Yankees are better at math than the Baltimore Orioles.
The logic breaks the same way. Just because race is caused by genes, and intelligence is influenced by genes, does not mean race influences intelligence.
And American, in the most common dialects of English, as spoken in Canada, the United States, the UK, Australia, New Zealand, India, and other places, means a citizen or expatriate of the United States of America.
And anyway, the GP has said specifically:
"Its why so much manufacturing has left the country. In in part why American is sliding from prominence all the while the pay divide has never been larger."
It's 100% clear he was talking about the US. There's no reasonable question about that.
It won't be outdated within a few months. It was released almost 2 years ago and won't be replaced until ... well the summary says "end of the year" but it links to something that Microsoft already repudiated. There isn't even a Beta yet as far as I know so I'm skeptical.
I think people have different ideas of what code reviews are. I think it's strange that we're talking about working with computers and everybody is assuming we're doing a face to face meeting with a single projected image.*
In my experience, people basically give me a source code change pack. I get around to looking at the diff when I get the time -- usually within the same day, next business day at latest. I read it myself, make my comments, ask questions, raise objections, and tell them I'm done with the current version. Then, when they get around to it, they send me a new change pack and I take a diff between the changes. Usually the second round is much quicker unless there was a major problem in the first round. Eventually we converge, and the final change is committed. Often for small changes I have no issues and it just goes in the first time. Big changes usually require the second round, occasionally three, very rarely more.
In some cases another reviewer or other reviewers will receive the same packs and do the same thing in parallel -- usually if the change crosses several components with different people familiar with each area. Each reviewer will probably focus on their own area and only make more cursory passes over the parts the other reviewer covers.
* Mind you, we do the projector thing where I work after we release a beta / release candidate, to increase the chances that the next one will be the last. We also do this when we're going to distribute a security patch. In both cases, the projector code review happens only after the more typical code review.
You are way better off entering feedback from actual customers, testers and UI designers, into an issue tracking system, prioritizing the issues, and working them down in order or priority.
By the time your customers are telling you your code is crap, a fix is usually several orders of magnitude more difficult -- and it's already burned your customer! I'm curious what sort of software you write that gives you this opinion -- maybe you ship broadly on a daily basis?
Testers are a valid way to find bugs, but they essentially work on a black box (if they aren't, then they are code reviewers...), which can make it difficult to see certain classes of problems.
As for UI designers, they are pretty much orthogonal to the concept of code reviews.
Code reviews short-circuit the process by ignoring the actual performance of the software
If your code reviews ignore the actual performance of the software, you're doing poor code reviews. It's almost never a good idea to do something poorly; the question of whether code reviews should be used should be read as, should decent code reviews be used. Of course you could argue that decent code reviews are impossible, but you don't seem to be arguing that.
instead using the quality of the source code as the measure of correctness.
The quality of the source code has a very obvious relationship to maintainability. Security is also something that just can't be put off until a user finds it. I can see your argument about robustness (crashes and hangs), that code reviews prioritize the issues you can see whether or not they are common issues -- but really this is the time when fixing them is easiest.
See, priority shouldn't just be about user impact of each bug. It should be user impact divided by the effort required to fix it -- this allows you to give the greatest user impact in aggregate per unit time. But of course, that's difficult to measure.
At the one extreme, bugs from users are prioritized by user impact alone because before investigation you don't even know how much effort is required to fix it (you can figure that out by sinking some time into investigating it).
Code reviews are at the opposite extreme -- it's prioritizing what's easy to fix when it's easiest to fix it, shrinking the denominator. However the user impact is somewhat hypothetical at this point. That said, you can often figure out that something is obviously going to be a frequent problem, eg. a narrow race condition that leads to heap corruption will be a pain in the ass to track down, probably relatively low hitting, with relatively high consequences including security problems. Similarly, a flaw in how text is localized will effect every customer who speaks languages A, B, C, & D.
Users don't care about the correctness of your source code as gauged by comparison to a specification.
You're talking about UI design again, it looks like. That's not the main use case for code reviews. Unless you're talking about a spec as in W3C or OpenDocument or something, in which case, your customers most definitely care.
I'm really curious about this. Could you describe an example? I've never seen the code quality go down objectively after a code review -- most objections I hear are that it's not cost-effective enough.
Subjectively, a cross-department change might be subject to differing coding standards, which might make person from organization A think he's making his code crappier to fit the ideas of organization B (where he's committing his code), because, I dunno, maybe organization B favours "goto cleanup" while organization uses a classic triangle error handling pattern. But from the perspective of the maintainers that's still a victory for consistency.
If the break is subtle and isn't detected, you could have a major system overhaul on your hands. This is particularly and tragically true of software where security is an issue.
To give an idea where I'm coming from, most of my experience is in very large pieces of widely-deployed systems software, where performance and security are both critical. These rules may well not apply if you're working on small to medium projects, or projects only for internal use in a company where all the users already have full read/write access.
I'm going to throw out a couple rules:
1. If you're not code reviewing all of your security-related code, you're not writing secure code.
2. All code is security-related until proven otherwise.
The same goes for maintainability, by the way. Only fixing things when they break and not looking at the things everybody else is doing is an almost certain way of propagating redundant slightly incompatible systems and creating a spaghetti dependency graph in the long run, at least for large software projects. Eventually you descend into a place where the product is almost always broken. To some extent, these things happen anyway with code reviews; they are just a tool to reduce the spread of the problem and even turn it back at times.
The "worse is better" mentality can work for other areas, notably performance. Developers do love to do premature optimizations at times. Even then I'd recommend at least one other person spare a thought of the high-level impact of nontrivial changes so nobody accidentally misses a fundamental flaw.
Your last sentence I actually agree with. That's why you'd do code reviews. Once the "good enough" code is in there, you'll have trouble scraping it out until it's too late. Until it's in there, it doesn't work. If you're going to take the regression risk of making a change, you might as well make the right change. Otherwise, you run that risk again when you fix the originally broken code.
"For someone else to go through all the code to the point that they understand all of it, they have to invest at least as much time as the coder."
I don't see why that would be true.
First off, if it's for a bugfix, you're completely glossing over the time spent identifying the root cause, design, & best fix. You're also forgetting the first-stage testing that the coder did themselves.
Second, if the code is well-designed and structured (and doesn't have a damn good reason to be obfuscated, eg. some hand-optimized assembly sequence), then it should be much easier to read than it ever was to write.
A book tends to take much longer to write than it does to read, even if you're the editor. A television show takes longer to film than to watch and critique.
I have to pull the cellphone out of my pocket and turn it on to tell the time. My cellphone runs out of batteries a nontrivial amount of times when I'm out. It's often doing something else that I don't want to lose. I have to frequently charge my cellphone during which time, if I stray from the cellphone, I don't have its timekeeping abilities. And I don't carry my cellphone 100% of the time, nor do I want to.
A watch has nearly perfect convenience for my purposes whereas using my cellphone is a bag of compromises.
I'd rather solve that problem with socialized healthcare than deliberately retarding progress for the sake of make-work jobs.
Has the time spent goofing off in a day / blowing off steam / etc. changed signficantly? I didn't live during this time so I don't actually have personal experience, but I suspect it's about the same for the same sort of job. Now, different job types might have had different proportions of time totally used up by things that aren't directly related to getting shit done, but that comes back to the difference between the 60s standard of living and that of today.
If you're asking me to keep my mouth shut deliberately, then isn't that tantamount to censorship?
What are you talking about?
You're the one who said "nothing to see here". Neither the GP nor the GGGP told you to keep your mouth shut.
The URL bar isn't there in the IE platform previews...
Not if you want security updates. That's the crux of the issue. Mozilla's old model continued providing security updates for some time on an otherwise-stable platform. Mozilla's new model does not -- all or nothing. You want to not be hacked by the hot new exploit, then you have to deal with the new interface changes they made, like it or not. And Asa specifically promised that would be the case.
Why shouldn't they be able to commercialize it?
I get not locking down knowledge with paywalls and patents, although patents are a bit funny because the whole point of functional patents is to encourage making knowledge freely available, via the mechanism of legally-enforced limited exclusivity on products. But I don't see why it's a problem to sell stuff enabled by new knowledge?
There's a difference between justifies and explains.
You can't just extend the timescale like that. The mechanics of almost everything we make have a peak beyond which you lose efficiency. Via time-honoured car analogy: find the velocity of peak efficiency of your car. Say 70kph. Is it more efficient to travel to your destination, which is 70km, and which you arrive at 1 hour later, driving at a constant 70kph, or in fits and starts of 140kph and 0kph (engine completely off, not even idling)? Okay, well, what if you took two hours and then traveled at 70km for the first hour and idled at the end? Scaling out time doesn't make a reasonable analogy.
The A/C is basically going to take a constant amount of time to go from the non-A/C temperature to the steady-state A/C temperature (assuming a constant outdoor temperature for simplicity), and during that time it's running less efficiently because the increasing temperature differentials by a non-infinitesimal amount is not a reversible process, so even the idealised process is inherently inefficient. Furthermore, it's a machine, not an idealism, and most machines tend to be less efficient when working at max capacity. The more often you turn it on and off, the more time in aggregate is being spent in this less efficient state. On the flip side, of course, you're not using any energy at all when it's off, so more time is being spent in a state of ultimate efficiency as well.
Where the optimal point is, I don't know exactly and it certainly depends on the characteristics of your air conditioning, your building, outside temperature, goal temperature inside, time spans you need to reach this goal temperature, tolerances, etc. I fully expect that 6 hours without air conditioning will outweigh a relatively short period of initial cooling.
How is that doublethink? You have a right to vote. You don't have a right to do any of the other things. Also, you're the only person to use the term "unfair"; that never even entered into it. The term is poll tax, and only showing ID to vote is a poll tax.
I kind of think it does make sense to need ID for voting, but then you should get free ID.