The Daily WTF: Curious Perversions in Information Technology

2011-07-12 Reply Admin

frits:
abico:
Amateur Troll:
It's a slow day at work...does anyone mind if I start a flame war?
By all means - or you can simply join one of the normal ones here. I'll get you started...
... frits - still poking his nose in where it's not required ...
I know this is a troll attempt. However, you've piqued my curiousity. What exactly do you mean?

And you have just got me wondering:

Your surprise at his assessment suggests you think his assessment of the others was accurate....

I assumed he randomly put some regulars into a basket and added reasonably random comments...We should remember it did start as a request for a flame war.

2011-07-12 Reply Admin

feugiat:
craig:
dohpaz42:
Both functions do the same thing, but in the former you would have to add 3x as many debugging breakpoints just to know why the function returned false. But, in the latter, you only have to add one debug breakpoint.

Incorrect, in the former you would have to add 3x as many debugging breakpoints to know that the function returned false.

In order to know why it returned false you require as many breakpoints (or debug statements) in both.
Why don't you check the return value at the other end (ie the calling function)?

There may be tens or hundreds of calls to a function.

Captain Oblivious · 2011-07-12 Reply Admin

abico:
Captain Oblivious is oblivious to the fact that no-one finds him very funny

Why would they? I don't come here to joke around.

2011-07-12 Reply Admin

reductio ad ridiculum:
feugiat:
craig:
dohpaz42:
Both functions do the same thing, but in the former you would have to add 3x as many debugging breakpoints just to know why the function returned false. But, in the latter, you only have to add one debug breakpoint.

Incorrect, in the former you would have to add 3x as many debugging breakpoints to know that the function returned false.

In order to know why it returned false you require as many breakpoints (or debug statements) in both.
Why don't you check the return value at the other end (ie the calling function)?
There may be tens or hundreds of calls to a function.

In that case, 3 debug statements really ain't much to ask. Or, you could create a Return function, that logs and returns.

Debugging break points are trivial to add anyways, and you can still add the one (before the first test) and then step through the code to see where it goes through the function - this would be more useful in seeing what we actually do too, I dare say.

I've never really understood why people insist on a single return point - I assumed it was to force them to use simpler functions, so it is a touch ironic that people would over-complicate functions to fulfill such a criterion.

Somewhere I once worked, our code went through all sorts of test to measure:

number of branch points (they wanted less than 10 for new code, 25 for legacy code that was modified)
Single return point
depth of nesting (I think at 5 they started to panic)
all variables initialized
freed pointers to be nulled and a whole host of other stuff. The idea was quality, though I'm not convinced that it worked so well. If you failed tests (most often branching) you would merely need to justify things along the lines of:
We use macros that have branches in them, which inflates the count, but ensures consistent reuse
We sanity check input variables (so each "if(x!=null)" could be excluded from the count) other things i forget - not that important.

Single return is at odds with reducing number of branching points (sort of) and avoiding too much nesting. It becomes difficult to do:

if(isValid(x))
{
  if(doSomething(x))
  {
    if(x.intValue() > 0)) return true;
  }
}
return false;

when you are conscious of depth.... it tends to lead to code that may be more difficult to understand:

if(isValid(x) && doSomething(x) && (x.intValue()>0))
{
  return true;
}
return false;

Now add a few more conditions, whack a few || in there, and it becomes more difficult to get your head around - but importantly, code complexity is reduced because there are fewer branching points....

2011-07-12 Reply Admin

I would like to thank You for this good article and please allow me to have the opportunity to express my satisfaction with the web hosting

2011-07-12 Reply Admin

To see a world in a grain of sand， And a heaven in a wild fllower， Hold infinity in the palm of your hand， And eternity in an hour.

2011-07-13 Reply Admin

boog:
esse:
boog:
The massive data allocation did cause a few raised eyebrows...
Exactly how many eyebrows did Paul have?
I thought we established a few weeks ago that 'few' might refer to 2
Interesting, but a few points to consider:

"Established" implies that we reached a consensus; I'm doubtful that such a thing has ever occurred on this site.

If Paul has only two eyebrows (which I'd expect is quite typical among people named Paul), why use a vague term like "few"?

Why is it assumed that "few" refers to a count of eyebrow raises at one point in time and not to multiple raises of an eyebrow over several time points?

2011-07-13 Reply Admin

trtrwtf:
dargor17:
Actually, it IS a limitation on our equipment, or rather, on our way of interacting with reality. Everything our eyes see, they see because there are photons coming from there into our eyes, and the same principle works when we "see" an electron or a nucleus or whatever with detectors. The problem is that a macroscopic object gets a negligible momentum transfer by interacting with a photon, while an electron gets a huge transfer, hence the uncertainty.
Remember, physics principles are always derived from observation.

I guess that an omniscent being could know position and velocity of an electron at the same time, but the thing is, science is about what humans can do, and we can't.

I an not by any means a physicist, and I'll say upfront that I don't have the math to understand how this works, but as it's been explained to me the limitation is more mathematical than experimental. That is, hoodaticus's explanation is closer to the truth, and the problem is not one of photons or any other particles bouncing off of things. The problem is that the total precision with which the actual values can be defined at any given time is limited.

That is, it's impossible to determine the values, not because the tools and medium of the experiments affect the situation, but because the actual acquisition of the knowledge affects the situation. More precisely, knowing the velocity of a particle with a certain degree of precision is what makes its position indefinite - not the process of measuring it.

This is difficult for me to accept, so I've asked a lot of smart people about it, and this is the consensus that I've extracted over the years. Still willing to hear more explanations, though, since as I say, I don't really understand it very well yet.

Well, there are actually various interpretations and philosophies of the uncertainty principle, but the point I'm trying to make is that "fundamental" principles are always derived from experiment through a process of abstraction. The reason why if you know the position of an electron with precision dx you know its velocity with precision h/dx is that to know where an electron is, you have to hit it with a photon and measure the photon scattering back to you, and if this happens it means that the electron took such an hit that its velocity has changed. This is a different matter from the experimental uncertainty coming from detector resolution, etc. It then becomes a "mathematical" principle: if we can't measure position and velocity at the same time, it's useless to worry about concepts such as trajectory, and so the concept of wavefuction and probability distribution come into use.

2011-07-13 Reply Admin

dargor17:
It then becomes a "mathematical" principle: if we can't measure position and velocity at the same time, it's useless to worry about concepts such as trajectory, and so the concept of wavefuction and probability distribution come into use.

Actually, I'm pretty sure it started out as a mathematical principle. Heisenberg uncertainty is a derived result, isn't it? It's based on the equations that described the particles in question well before they were observed. It's not based on trying to explain why people were having trouble detecting the position and velocity of subatomic particles. So while I think it's true enough that trying to measure the position and velocity of the balls on a frictionless pool table by bouncing the cue ball off of them is not going to be very informative, I'm pretty sure that problem is a retroactive explanation bolted on to Heisenberg's principle, not the basis for it.

2011-07-13 Reply Admin

The Nerve:

Fixed?

int errors=0;          
  try
  {
	// LOG_E_BREAK("");
    	int const nMatrices=m_rawData.nMatricesX()*m_rawDataDim.nMatricesY();
	errors+=m_CCDDataGainArr.SetSize(nMatrices);
	//LOG_E_BREAK("");
} finally {}
return errors;

No. No "finally" in C++.

2011-07-13 Reply Admin

trtwtf:
dargor17:
It then becomes a "mathematical" principle: if we can't measure position and velocity at the same time, it's useless to worry about concepts such as trajectory, and so the concept of wavefuction and probability distribution come into use.

Actually, I'm pretty sure it started out as a mathematical principle. Heisenberg uncertainty is a derived result, isn't it? It's based on the equations that described the particles in question well before they were observed. It's not based on trying to explain why people were having trouble detecting the position and velocity of subatomic particles. So while I think it's true enough that trying to measure the position and velocity of the balls on a frictionless pool table by bouncing the cue ball off of them is not going to be very informative, I'm pretty sure that problem is a retroactive explanation bolted on to Heisenberg's principle, not the basis for it.

Well, going by http://www.aip.org/history/heisenberg/p08.htm I guess that the principle was an intuition derived from the known data.

Still, I must admit that even though I know some quantum mechanics (I'm a physics grad student) I'm a bit lost on the exact process that lead to its development...

But my point is: the uncertainty principle is a limitation of what humans can know and therefore measure. Quantum mechanics is just saying: "ok we can't measure that stuff, let's work around that to see what we can measure instead". And the physical motivation for that limit is that to measure something you have to interact with it, therefore changing its state.

2011-07-13 Reply Admin

dargor17:
But my point is: the uncertainty principle is a limitation of what humans can know and therefore measure. Quantum mechanics is just saying: "ok we can't measure that stuff, let's work around that to see what we can measure instead". And the physical motivation for that limit is that to measure something you have to interact with it, therefore changing its state.

No argument on this. As I say, I'm not a physicist, only an interested civilian, so what I say should be taken with a grain of salt, plus the salt shaker and the Morton factory, for good luck. In any case, I think we've managed to agree on this statement: "Heisenberg is not about what we can measure, it's about what we can know." Or, perhaps, "... it's about what can be known." Or, if you prefer "... it's about the way the world can be."

boog · 2011-07-13 Reply Admin

cyborg:
boog:
esse:
boog:
The massive data allocation did cause a few raised eyebrows...
Exactly how many eyebrows did Paul have?
I thought we established a few weeks ago that 'few' might refer to 2
Interesting, but a few points to consider:

"Established" implies that we reached a consensus; I'm doubtful that such a thing has ever occurred on this site.

If Paul has only two eyebrows (which I'd expect is quite typical among people named Paul), why use a vague term like "few"?
Why is it assumed that "few" refers to a count of eyebrow raises at one point in time and not to multiple raises of an eyebrow over several time points?

I'm not assuming that "few" refers to eyebrow raises; I'm assuming (quite ridiciously, I might add) that it refers to the total number of eyebrows that were raised.

xtremezone · 2011-07-13 Reply Admin

gallier2:
Yes, my colleague uses that construct, I hate him for that. It's completely retarded. If you conceptually need a goto (and an error exception is a good reason for a forward goto), do a goto. The break is a goto,...

YES, thank you! Anybody stupid enough to add a fake loop to avoid a goto needs to be beaten and then fired. GTFO, TITS or not.

2011-07-14 Reply Admin

boog:
I'm assuming (quite ridiciously, I might add)

Pointless troll - got ya.

2011-07-14 Reply Admin

Anyone talking about reasons to fire a C++ programmer while clearly having not a clue about C++ should be beaten and then fired.

int f (int x) { if (x == 0) goto exit; int y = x + 1; x = y * y; exit: return x; }

compiles fine in C but not in C++.

2011-07-14 Reply Admin

MasonicParrot:
Strange that no-one has mentioned using exceptions to achieve error handling. We're talking about C++ after all.

Ugh! You want to add exceptions to code like this? Go. Read. Sutter. Now.

M4

boog · 2011-07-14 Reply Admin

cyborg:
boog:
I'm assuming (quite ridiciously, I might add)
Pointless troll - got ya.

Yes, because humor == troll, right?

2011-07-15 Reply Admin

boog:
cyborg:
boog:
I'm assuming (quite ridiciously, I might add)
Pointless troll - got ya.
Yes, because humor == troll, right?

No.

Now, direct me to the humour.

C-Octothorpe · 2011-07-18 Reply Admin

cyborg:
boog:
cyborg:
boog:
I'm assuming (quite ridiciously, I might add)
Pointless troll - got ya.
Yes, because humor == troll, right?

No.

Now, direct me to the humour.

Wow, you must be a blast to hang out with in real life...

2012-02-04 Reply Admin

CLUELESSNESS ALTERT

This is what's wrong with "the nerve"'s code: C++ Doesn't have "finally".

2012-02-04 Reply Admin

Shouldn't it be this "bla"?

do
{
frist();
} while(1);

'cause while(0) won't execute the block (again). and frist will err-out because it isn't a function call.

The Legacy Handover

Leave a comment on “The Legacy Handover”