This is indeed easy—but very inaccurate: it can lead to the measurement being out by as much as 30%.

The problem is that flour is compressible—so measuring it by weight is inherently more accurate.

No, it can be any expression or any type. Doesn't have to be a symbol, and doesn't have to be constant.

... and is a suitable replacement for every piece of software ever? Wow!

I wish I lived in your world where there was always an alternative that's well-documented and sane... in fact, I'd settle for well-documented OR sane ;-)

You are aware that there are CPUs capable of executing Java bytecode directly? I.e. that use Java bytecode as (one of) their native assembly instruction set(s)?

I assume you're talking about Police and Crime commissioners, in which case no, they're not serving police officers, and indeed police officers are barred from holding that office.

You're right, the article does say that, but I wouldn't be surprised if it was the (non-UK) newspaper that mixed up"University of Sussex at Brighton" and "University of Brighton"...

That's not true - it's perfectly possible to give a specification that's complete and comprehensive, and yet is not executable by a computer.

For instance, you could specify a "sort" function by saying that (1) it must return a list that contains a rearrangement of the items passed in, (2) that list must be in ascending order, (3) the time taken must be less than K*n*log(n), where n is the number of items passed in.

I've given that specification in English for brevity, but you could equally specify it in a more formal way - and indeed in one that the computer could verify for any instance of the problem that you put in. (Some might call this "specifcation by unit test".) But the computer could not, in general, go from the specification to an implementation completely automatically.

... provided that the number of files fits into the command line argument space (a common reason for using find/xargs rather than, say, wildcards/backticks, aside from the security issues).

As it happens I've been using perl for longer than your 17 years of JavaScript, so I'm well aware of how its references work... but nothing about that changes the fact that your assertion about JavaScript's "==" comparing values is wrong; in fact, it would be truer to say that "===" compares values.

I know how variables work, thanks ;-). Assignment is how you change a variable's value in imperative languages. You can't just arbitrarily assert that words like "change" and "modify" have different meanings from their standard ones..

I've got a very good idea what a "value" is. One property of values (in the context of computing) is that, if two things have different effects when passed to the same function, then they're different values. Perhaps you have a different definition of "value" that contradicts this? If so, do enlighten us, and can you provide a link to a credible source to back up your definition? Again - you can't just arbitrarily assert that words have different meanings from their standard ones.

Haha... actually none of the above are true. And even if they were - your assertion about "==" would still be wrong, so your comment to angel'o'sphere to "try harder" would still be uncalled for.

I agree that one of us is, indeed, quite confused :-)

Yes it is - it's an example of your explanation being wrong. Here are some more. You claimed:

However,

a = "1";
b = true;
result = (a == b);

... gives a result of true - when clearly "1" and true are different values - for instance, you'll get different results if you pass them to alert(). You also said:

"Pointing to the same place in memory" and "actually being the same variable" are two entirely different concepts. For example, after:

a = {foo: 1, bar: [1,2,3]};
b = a;

then 'a' and 'b' refer to the same object ("point to the same place in memory", if you like), and a===b will return true. But they're still different variables, because after modifying one of the variables

b = {};

the other variable will not be affected in any way.

The reason for wanting to use triple-equals is not because "double-equals compares values", it's because double-equals sometimes behaves in a way that's confusing and not very useful. For instance, I'd expect, for any sensible equality operator, that if a==b and b==c, then a==c... but for JavaScript's double-equals, that's not true (put a="", b=[], c="0" - then ""==[], and []=="0", but "" != "0"...)

Close... acutally his name was Edgar Frank "Ted" Codd

Tthat logic makes no sense. As you say, most people haven't done anything wrong. You say that bad treatment can't be punishment if the person undergoing it didn't do anything wrong. Therefore intrusive gun control is, by your own reasoning, not punishment for those people, and your statement is hyperbole if mine is. You can't have it both ways.

Yes... you are. I'm explaining why it's important to consider the negative impact of gun crime as well as the negative impact of gun control measures, in order to be come to a balanced conclusion on whether any given gun control regime, or absence thereof, should be implemented. Do you disagree with that?

Because what you appear to be saying is that one should ignore the victims of gun crime when considering what the law should be. (That may not, in fact, be your position, but it's what your words are suggesting.)

Haha, I'm using hyperbole? Wasn't it equally hyperbole when you talked about the "population as a whole" being punished - or do you consider being part of the population a punishable offence? ;-)

The point is that, to make a balanced comparison, you have to consider the positive and negative effects experienced by everyone in society. If (and, of course, it is very much an "if") the negative effects on the population as a whole of (insert proposed freedom-reducing gun control measure here) are less than the positive effects that come from people not getting shot as a result, that's a strong argument that that measure should be implemented; if that's not the case (because the measure is so draconian that its negative effects are large, and/or the measure is not effective, or actually counterproductive, in reducing gun crime injuries), then the measure should clearly not be implemented.

Balancing these factors is hard to do in any scientific way - not least because the value of "freedom" versus the value of not being shot is very hard to pin down quantitavely - but neglecting the harm done by gun crime is bound to unbalance the equation.