sugar: 50% fructose, 50% glucose
HFCS: 55% fructose, 45% glucose zomg, clearly hfcs is the reason people are getting so much fatter.
It's not that simple.
Do a little reading about it. Your body has to expend energy/effort to break sugar into fructose + glucose, whereas with HFCS, the fructose and glucose are already separated and your body has immediate use of them. This is the kicker, and why HFCS is worse than sugar. Of course, even worse than HFCS is fruit juice that's high in fructose.
Re:Not answered in review
on
iOS 8 Review
·
· Score: 1
It'd only be nice if you have a filing fetish. It's not useful. Any minor pleasure it might bring filing fetishists would be vastly outweighed by those ordinary phone users who lose applications.
That's a rather naive thing of you to say. Some of us have a hundred apps installed, and it's very useful to have them organized and be able to select them quickly with just a couple or three taps, rather than scrolling through dozens of pages of grids.
More to the point, when people use, "Google," as a verb, they mean to actually use Google, as opposed to using any brand of facial tissue available when saying, "Kleenex."
Exactly! You can't google something using Bing, for example. Not that you'd want to anyway. You can only google something using Google.
(Now I feel like I need to go wash my hands after mentioning Bing. Eww.)
Don't feel bad. It's tricky wording. I wasn't sure how to word it to be clear (and to be fair, I don't think it was really clear). "Opposites" to me would imply 180 opposing... so I wrote "mirror-opposites" to imply a vertical mirror, but of course that's pretty subtle and not very unambiguous.
I'm pretty sure, though, that even any class that requires you to use equals(), you can still use == as a fast-precheck. That is, a==b implies a.equals(b) for all objects a,b in all classes. The converse, of course, is not the case: a.equals(b) does not imply a==b. And the inverse is not true: a!=b does not imply !a.equals(b). But the contra-positive is true: !a.equals(b) does imply a!=b.
Yes "clever" operator overloading comes up high in my list.
Scripting languages are full of it like in Pike: str/" " Divide a string by space to get an array of the words.
But I dislike it way more when operator overloading abuse is done in user code than when it is a language construct.
So, if you take that array of words and multiply it back by " ", do you get the original string? Because that would make it cool.
That's a really dumbass lexer. Glad that shit got fixed.
Or should I say... a really dumbass parsing layer to go and use a lexer that doesn't understand the local context when it constructs a lexeme from the input stream.
Namely, the >> symbol. Because templates use angle brackets for template parameters, if you had a nested template such as T<int, T1<double> >, you HAD to put the space between the two closing angle brackets. Otherwise the lexer would interpret the two angle brackets as the shift operator.
That's a really dumbass lexer. Glad that shit got fixed.
Ok, cool... Ya, after I posted that and re-read it, I thought to myself, "I wonder if he was referring only to Integer, in which case I'm going to feel like an a-hole for being so harsh." Apologies if I came across as harsh.
Question... what did you mean by "For any kind of object" then?
No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and...
Oh my god. Excuse me, but you are so very wrong. Yes, it DOES work and is a GOOD THING to compare references sometimes. For example, if you are implementing your own general hash-based collection class, you will find that your lookup code runs significantly faster if you first compare object references for equality before comparing the object's hash followed by comparing the objects themselves for equality. That is to say: (1) First compare object references using ==. If equal, you're done immediately because your key matches, and you can go fetch the object associated with the key. If not equal, proceed to next step. (2) Next, compare object hashes using ==. If not equal, you have a mismatch and you look at the next key/value pair, if present in the bucket or linear addressing cycle; if equal, proceed to next step. (3) Finally, assuming you get this far, compare contents of objects. If equal, then you have a key match; if not equal, you have a mistmach and you either continue for the next key or fail with no object found.
So you see, sometimes is makes perfectly good sense to compare object pointers. Comparing references instead of values is NOT logically wrong — as long as you use the comparison as an early-out test before performing the more expensive actual comparison of value. Hope that clears things up.
Slashdot Mirror
sugar: 50% fructose, 50% glucose HFCS: 55% fructose, 45% glucose
zomg, clearly hfcs is the reason people are getting so much fatter.
It's not that simple.
Do a little reading about it. Your body has to expend energy/effort to break sugar into fructose + glucose, whereas with HFCS, the fructose and glucose are already separated and your body has immediate use of them. This is the kicker, and why HFCS is worse than sugar. Of course, even worse than HFCS is fruit juice that's high in fructose.
I think you meant to say:
But it isn't linear, it is exponential...
It'd only be nice if you have a filing fetish. It's not useful. Any minor pleasure it might bring filing fetishists would be vastly outweighed by those ordinary phone users who lose applications.
That's a rather naive thing of you to say. Some of us have a hundred apps installed, and it's very useful to have them organized and be able to select them quickly with just a couple or three taps, rather than scrolling through dozens of pages of grids.
A good Waterfall approach gets 4x more done than any version of Agile
Citation needed
More to the point, when people use, "Google," as a verb, they mean to actually use Google, as opposed to using any brand of facial tissue available when saying, "Kleenex."
Exactly! You can't google something using Bing, for example. Not that you'd want to anyway. You can only google something using Google.
(Now I feel like I need to go wash my hands after mentioning Bing. Eww.)
Ya, I should have stated mirror-opposites assuming a vertical mirror line (which is what's relevant/important when it comes to hands on the wheel).
Don't feel bad. It's tricky wording. I wasn't sure how to word it to be clear (and to be fair, I don't think it was really clear). "Opposites" to me would imply 180 opposing... so I wrote "mirror-opposites" to imply a vertical mirror, but of course that's pretty subtle and not very unambiguous.
Existing POS software for school cafeterias already can cross-reference the enrollment records and photos.
What exactly makes you think it's piece-of-shit software?
Yes they are. Mirrored along the vertical axis.
In reality, it turns out, 9:30 and 3:30 are safer.
Oh yeah? 9:30 and 3:30 are not mirror-opposites. Did you mean 9:30 and 2:30?
And always compress your logs before flushing them out to archive!
Is recent activity contained in a log?
Yup, and the logs are even rotated!
I'm pretty sure, though, that even any class that requires you to use equals(), you can still use == as a fast-precheck. That is, a==b implies a.equals(b) for all objects a,b in all classes. The converse, of course, is not the case: a.equals(b) does not imply a==b. And the inverse is not true: a!=b does not imply !a.equals(b). But the contra-positive is true: !a.equals(b) does imply a!=b.
Ok, so it's the developer's fault for not using lint then.
:-)
Yes "clever" operator overloading comes up high in my list. Scripting languages are full of it like in Pike: str/" " Divide a string by space to get an array of the words. But I dislike it way more when operator overloading abuse is done in user code than when it is a language construct.
So, if you take that array of words and multiply it back by " ", do you get the original string? Because that would make it cool.
That's a really dumbass lexer. Glad that shit got fixed.
Or should I say... a really dumbass parsing layer to go and use a lexer that doesn't understand the local context when it constructs a lexeme from the input stream.
Namely, the >> symbol. Because templates use angle brackets for template parameters, if you had a nested template such as T<int, T1<double> >, you HAD to put the space between the two closing angle brackets. Otherwise the lexer would interpret the two angle brackets as the shift operator.
That's a really dumbass lexer. Glad that shit got fixed.
They should of used:
s/of/have/
I know one game shipped with buggy AI because somebody forgot to use two equal signs inside an if statement!
That's not C's fault. That's the developer's fault for ignoring the compiler warning about it. (Or for not having enabled the warning.)
Documentation for sizeof would have told you that it's for telling you the size in bytes of datatypes on a particular system.
s/bytes/chars/
example: uint32 is a 32-bit unsigned integer,
s/uint32/uint32_t/ (unfortunately)
Ok, cool... Ya, after I posted that and re-read it, I thought to myself, "I wonder if he was referring only to Integer, in which case I'm going to feel like an a-hole for being so harsh." Apologies if I came across as harsh.
Question... what did you mean by "For any kind of object" then?
The core problem is that Java was never indented as a mainstream language, but for embedded programming.
s/never/not originally/
FTFY
No, it never works. Ever. For any kind of object. Comparing references instead of values is logically wrong, it does not make sense, and ...
Oh my god. Excuse me, but you are so very wrong. Yes, it DOES work and is a GOOD THING to compare references sometimes. For example, if you are implementing your own general hash-based collection class, you will find that your lookup code runs significantly faster if you first compare object references for equality before comparing the object's hash followed by comparing the objects themselves for equality. That is to say: (1) First compare object references using ==. If equal, you're done immediately because your key matches, and you can go fetch the object associated with the key. If not equal, proceed to next step. (2) Next, compare object hashes using ==. If not equal, you have a mismatch and you look at the next key/value pair, if present in the bucket or linear addressing cycle; if equal, proceed to next step. (3) Finally, assuming you get this far, compare contents of objects. If equal, then you have a key match; if not equal, you have a mistmach and you either continue for the next key or fail with no object found.
So you see, sometimes is makes perfectly good sense to compare object pointers. Comparing references instead of values is NOT logically wrong — as long as you use the comparison as an early-out test before performing the more expensive actual comparison of value. Hope that clears things up.
I don't like to put trust in people who write "Gates's"
And three times in the same sentence! (Legal, but annoying.)
Relax, you'll be in good hands soon. The wambulance has been called and should be arriving shortly.
Gates's is the clearest form of the possessive nominative.
Thank you for finding that!
[...] It gave us the notion of an "app" and an idea of apps could achieve in the Internet era.
Applet actually.
The notion of an "app" didn't come until 2008 with the iPhone.