You keep telling yourself that blowing up a van full of people helping wounded people is justifiable. I watched the video, and I can see some justification for the initial shooting, but the van is completely indefensible. Only a mouth breathing sock puppet sociopath would try to defend the actions of that trigger happy gunner.
Java is getting closer, but not "as fast or faster" than C++ or C. At least the last time I looked at any half-way competently executed benchmarks. Maybe you have some new benchmarks for me to look at?
There's this core assumption in your post that geographical areas are somehow important independent of the people that live there, that somehow a person occupying 100 square miles is more important that a person occupying 1/10th of an acre. Land without people is just land. People without land are still people.
Find a bike that doesn't have an angle on the front wheel fork that's acute where it meets the ground going back toward the bike. Well, you won't find one because it would be extremely hard to keep it up right. You're wrong.
Use one or the other consistently? But they don't mean the same thing.
They compile to the same thing if they are both used with the meaning "increment this thing by one". If they are used to mean "increment-then-evaluate" or "evaluate-then-increment", one may as well separate the increment from the evaluate because the combination only (maybe) makes it easier for the lexer/parser, not the next human assigned to maintain the code X years later.
I'm fine with "i += 1" or even "i = i + 1". If I want to increment, I increment; if I want to evaluate, I evaluate.
Easier for the parser/lexer? Really? No, pre-increment and post-increment are not to make the parser's job easier, they are to make code more concise, easier to read, allow concise and common idioms for humans.
Here's an example extending an array foo:
foo[len++] = "I";
foo[len++] = "like";
foo[len++] = "big";
foo[len++] = "butts";
Can they be abused? Sure. Just like everything. If you don't grok that, go back to python.
Example: in C-like languages that support pre- and post-increment, I expect the code to use only one or the other consistently, and never mix it with another expression.
Use one or the other consistently? But they don't mean the same thing.
Angular momentum is not the primary cause of why bicycles are easy to balance when moving. It's more about dynamic stability, you lean left, the front wheel moves in a way to shift the center of gravity back over both wheels' contact points. Some guy did an experiment to negate the angular momentum of the wheels to prove it.
Holy shit, this guy is on to something. You could write these common computing tasks as a sort of "bench" suite of tests. Then on each architecture, you would get different "marks" against the "bench". Let's call them "benchmarks" for brevity. These "benchmarks" would give allow clear and unambiguous comparison of these various chips. Foolproof and brilliant!
Slashdot Mirror
I bow to your superior argument.
You keep telling yourself that blowing up a van full of people helping wounded people is justifiable. I watched the video, and I can see some justification for the initial shooting, but the van is completely indefensible. Only a mouth breathing sock puppet sociopath would try to defend the actions of that trigger happy gunner.
To a more interesting show?
xkcd links - the new hot grits
Because saying life can survive somewhere is different than saying it can evolve somewhere.
And even if they said life can evolve somewhere doesn't mean is has evolved there.
And even if the said life has evolved there doesn't mean that it should have evolved there.
~ 2x performance for 10x the cost is the definition of "not by much"
Wait, you go to a bar that features public singing, and the you complain that there is public singing? You might want to have that looked at.
I wish I hadn't commented in this discussion so I could mod you up. Also, I wish I had mod points.
Java is getting closer, but not "as fast or faster" than C++ or C. At least the last time I looked at any half-way competently executed benchmarks. Maybe you have some new benchmarks for me to look at?
Not quite, try again.
There's this core assumption in your post that geographical areas are somehow important independent of the people that live there, that somehow a person occupying 100 square miles is more important that a person occupying 1/10th of an acre. Land without people is just land. People without land are still people.
You can negate angular momentum, it's a vector quantity. How about a ski bike? Still stable while moving.
Find a bike that doesn't have an angle on the front wheel fork that's acute where it meets the ground going back toward the bike. Well, you won't find one because it would be extremely hard to keep it up right. You're wrong.
Pro-tip: if you're going to be a douche on-line, be sure to login for that extra personal touch.
Use one or the other consistently? But they don't mean the same thing.
They compile to the same thing if they are both used with the meaning "increment this thing by one". If they are used to mean "increment-then-evaluate" or "evaluate-then-increment", one may as well separate the increment from the evaluate because the combination only (maybe) makes it easier for the lexer/parser, not the next human assigned to maintain the code X years later.
I'm fine with "i += 1" or even "i = i + 1". If I want to increment, I increment; if I want to evaluate, I evaluate.
Easier for the parser/lexer? Really? No, pre-increment and post-increment are not to make the parser's job easier, they are to make code more concise, easier to read, allow concise and common idioms for humans.
Here's an example extending an array foo:
foo[len++] = "I";
foo[len++] = "like";
foo[len++] = "big";
foo[len++] = "butts";
Can they be abused? Sure. Just like everything. If you don't grok that, go back to python.
Sure, if you don't use them for what they are designed for, they have the same effect. But they still don't mean the same thing.
233 comments and not one mention of ctags or cscope yet.
Example: in C-like languages that support pre- and post-increment, I expect the code to use only one or the other consistently, and never mix it with another expression.
Use one or the other consistently? But they don't mean the same thing.
Angular momentum is not the primary cause of why bicycles are easy to balance when moving. It's more about dynamic stability, you lean left, the front wheel moves in a way to shift the center of gravity back over both wheels' contact points. Some guy did an experiment to negate the angular momentum of the wheels to prove it.
Thanks for the play-by-play breakdown of your experience reading his post. Fascinating.
Holy shit, this guy is on to something. You could write these common computing tasks as a sort of "bench" suite of tests. Then on each architecture, you would get different "marks" against the "bench". Let's call them "benchmarks" for brevity. These "benchmarks" would give allow clear and unambiguous comparison of these various chips. Foolproof and brilliant!
Better?
I didn't have to read very far to find out that no, the law is not a reality. Thanks, slashdot!
How is that sad?
He could have taken the rest of the week off at his ranch in Texas and it would not have made any difference. Colossally poor judgment.