The Daily WTF: Curious Perversions in Information Technology

2008-07-30 Reply Admin

More important than the finalize, was Min hot? My company should use that as a hiring requirement.

2008-07-30 Reply Admin

So, why not just fire him for being incompetent? How did you know that he and the clairvoyant were even the same person? Seems awfully petty to me, dog forbid he share the same name as a sex offender.

(captcha "acsi")

2008-07-30 Reply Admin

The Vicar:
Brandon:
if(computer.IsOver || computer.IsAboutToBeOver) { //execute critical business code }
I win.
You forgot to add

if(Virus == Very Yes)

You won, but that's not a good prize.

I also forgot to check for the "Flagrant System Error" in the first place. I guess that could get included in the "computer.IsAboutToBeOver" variable.

cconroy · 2008-07-30 Reply Admin

Joseph:
Does Min know Max?

Yes. They met at AVG.

2008-07-30 Reply Admin

Steve:
<snip>
"Max" eventually got reassigned to another group which, to the best of my knowledge, has never produced anything beyond interiminable meetings and hangs on by attaching itself remora-like to other successful projects. Everyone seems happy.

You forgot the part where Min marries Max, they have a child named Avg, and then they all lived happily ever after.

2008-07-30 Reply Admin

At this point, I suggested that his solution was flawed - what if the circular reference did not point back to the first element, it would fail to detect it, such as:
A points to B which Points to C which points back to B. In this case you'll never get back to 'A'.

He ended the interview at this point and I never heard from them. Not sure if this was the reason why they did not call back or if it was just due to other reasons... or my solution was shitty... I guess I don't really care, the job was downtown, which I try to avoid like the plague.

I don't know about your solution, but his solution was flawed and I would guess that his ego was what ended the interview.

2008-07-30 Reply Admin

JonC:
Surely TRWTF is giving someone who has 'Oracle T-SQL' and 'Microsoft Solaris' on their CV the benefit of the doubt.
That would have been setting alarm bells ringing immediately for me.

Yeah, but it will pass HR screening. HR is the real WTF.

2008-07-30 Reply Admin

Was Min cute? ;-)

2008-07-30 Reply Admin

As far as I'm concerned lying to get an interview is different than lying THROUGH an interview.

What Min did, in my eyes, was not lying. Now, the article presents it in such a way that we are to believe she had no coding skills at all. So, okay, she wasted the interviewers time. But when you consider that applicants are almost always passed through an HR person who is non-technical in SOME cases lying makes perfect sense.

I was a C# developer that relocated across the country to a small town with limited employment opportunities. There was a company hiring for a VB.Net developer and they required 1-2 years of experience with VB.Net.

I had 0 years of experience with VB.Net but I was a decent junior level C# developer. Aside from not having any VB.Net experience I was really a good fit for the job. I changed my resume to say 'C#/VB.Net Developer' at my last job. Because I did that, my resume made it to level 2, an actual developer/manager who would be the one doing an actual interview.

The interview itself went well. I was given a technical test, in VB.Net. I was able to pass it. I also explained in the interview that the 'majority' of my previous work was in C# and not VB.Net but that there were certainly more similarities than differences between the two, what with the same .Net Framework and all.

I ended up getting the job. Had I not changed my resume I would not have gotten an interview.

real_aardvark · 2008-07-30 Reply Admin

zoips:
anon:
I almost never use finally, if you want to do stuff after a try-catch block then you don't really need the finally, these two blocks are almost always the same:
try { result = a/b } catch (exception) { //handle divide by 0 } finally { return result }

try { result = a/b } catch (exception) { //handle divide by 0 } return result

also, any "mission critical" tasks would fare the same, and should have been recorded in a log system like a database uses instead of being 100% reliant on the code always executing

finally is intended for (an attempt at) graceful cleanup when you plan to propagate the exception up the stack. At least that's always been my impression.

Ah yes, the finally block: the goto of the modern world. An impression that many of the comments above reinforce.

Then again, I got involved today in a half-hour's worth of heated discussion on the semantic benefits of using a while loop in C where a for loop was proposed, even though I know that in an abstract sense they're identical. Reliance on a 'break' statement seems to offend my maintenance-programmer sensibilities, I suppose.

That reminds me -- must go off and check the C99 standards question that occupied the other seven and a half hours. Ta-ta!

2008-07-30 Reply Admin

// this comment will be read regardless of how you leave the site. }

Sutherlands · 2008-07-30 Reply Admin

WhiskeyJack:
Sutherlands:
The correct answer to the question you were asked is: Create 2 pointers, one that traverses the list one at a time, and one that traverses the list two at a time. If they are ever equal, you have a circular reference. If you encounter the end, you don't. However... that only works when you're not trying to find the beginning of the list... which my interviewer decided to add on to the question. (The actual question is from what Google made up for one of their interviews when they were hiring, btw)

I'm not grokking this. Is there an explanation somewhere of how that would work?

Someone posted a solution already, but here's a simplified one.

boolean isCycle(*head) { slow = fast = head; try { do { slow = slow->next; fast = fast->next->next; }while(slow != fast) return true } catch(NPE) { return false } }

so if the fast one gets to the end of the list, there's no cycle. If the slow one meets the fast one, you know the fast one looped around at least once.

Vechni · 2008-07-30 Reply Admin

Markp:
Contractor Khan:
VB life support machines. *Shudder*.

Is that a) life support machines developed in VB, or b) Min, the "machine" used to keep a VB application alive?

i don't understand "life support" i just said i did so maybe i get job? and maybe i save life?

real_aardvark · 2008-07-30 Reply Admin

Satanicpuppy:
Transactions don't mean jack until they're committed. That's the whole point. If it fails in the middle, the database will just toss the info as a bad write. If it fails the commit, same thing. If the commit succeeds, then there is no problem.
Transactional databases can't have bad or incomplete writes. That's just the way it works.

Granted that they minimise them. This is, however, a preposterous statement in the absolute. "Hello, little cosmic ray -- please don't burn a teeny but catastrophic hole in my transaction log."

In a more realistic scenario, you'are asking an awful lot of the disk hardware. Let's assume that the db/OS in question conscientiously flushes through cache and RAM and paging system to the actual storage. What guarantee do you have that bits of your transaction log aren't stuck in the disk controller logic, and haven't yet reached metal oxide?

I imagine that there might be an extremely sophisticated and locked-in system that could make this guarantee -- possibly through some sort of staggered RAID -- but it would be slow as shit and I doubt generally available.

I worked on an OS file-system with built-in ISAM and transactional support, running on fault-tolerant hardware, and believe me, when it went down hard, all this guaranteed you was a half-day waiting for expensive dedicated support to patch the end of the base files back together again.

real_aardvark · 2008-07-30 Reply Admin

blah:
TRWTF is this article has more sloppy typos than Min's resume's bad Engrish.

What, then, makes you suppose that Min's resume contained any bad English?

2008-07-30 Reply Admin

danixdefcon5:
Same I thought. Finally blocks always execute, the only way they wouldn't execute would be in situations where no code will get executed, like kill -9'ing the process, or on power down. Anyway, any critical transactions should be inside a transaction block themselves, so these two cases would cause an auto-rollback anyway!
Note: finally blocks will run even if the exception thrown is an unchecked one (i.e. RuntimeException).

No need for anything exotic. Even Visual Basic's ridiculous "End" command will abort finally blocks:

Module Module1
    Sub Main()
        MsgBox("Started!")
        Try
            End
        Finally
            MsgBox("Ended!") ' Never executed
        End Try
    End Sub
End Module

2008-07-30 Reply Admin

I heard that Paula Bean is now Min's supervisor.

2008-07-30 Reply Admin

Looks like Mi 'won'. Guess it goes to show, well all have to cut our teeth somewhere (somewhere else preferably)

2008-07-30 Reply Admin

morry:
where are you supposed to put the code? Magic fairy blocks?

That's actually a genious idea. I propose this as an addition to the next version of the .NET framework.

try {
    doStuff();
}
finally {
    semiCriticalTransactionCode();
}
magicFairyFinally {
    // Will ALWAYS run, even if the machine has no power
    criticalTransactionCode();
}

2008-07-30 Reply Admin

Sutherlands:
Someone posted a solution already, but here's a simplified one.
boolean isCycle(*head) { slow = fast = head; try { do { slow = slow->next; fast = fast->next->next; }while(slow != fast) return true } catch(NPE) { return false } }

so if the fast one gets to the end of the list, there's no cycle. If the slow one meets the fast one, you know the fast one looped around at least once.

This will work, but using try/catch that way is really not a best practice. The previous solution, which explicitly checked for the null values is a better solution. (Even though they achieve the same thing exactly, and my argument is largely based on coding semantics.)

Also, the previous solution would be (almost immeasurably) faster, as exceptions are hardly the speediest operation. If you were doing N of these comparisons each unit time, you'd be wasting a lot of resources just handling that NPE.

Also, captcha was 'nulla'.

2008-07-30 Reply Admin

real_aardvark:
In a more realistic scenario, you'are asking an awful lot of the disk hardware. Let's assume that the db/OS in question conscientiously flushes through cache and RAM and paging system to the actual storage. What guarantee do you have that bits of your transaction log aren't stuck in the disk controller logic, and haven't yet reached metal oxide?

Flush() guarantees this. Of course, in the catastrophic case, that fails and you use backups. You can't be perfect, but you can get close.

2008-07-30 Reply Admin

JL:
Even Visual Basic's ridiculous "End" command will abort finally blocks

Speaking of the End command...

http://www.devx.com/tips/Tip/12443

2008-07-30 Reply Admin

Franz Kafka:
real_aardvark:
In a more realistic scenario, you'are asking an awful lot of the disk hardware. Let's assume that the db/OS in question conscientiously flushes through cache and RAM and paging system to the actual storage. What guarantee do you have that bits of your transaction log aren't stuck in the disk controller logic, and haven't yet reached metal oxide?

Flush() guarantees this. Of course, in the catastrophic case, that fails and you use backups. You can't be perfect, but you can get close.

Flush() is broken, then what do you do?

Jeff S · 2008-07-30 Reply Admin

real_aardvark:
Ah yes, the finally block: the goto of the modern world. An impression that many of the comments above reinforce.

Huh? So what are you saying? You believe that using Finally is a bad practice? I have no idea what correlation you are drawing between finally() and goto...

2008-07-30 Reply Admin

I almost never use finally, if you want to do stuff after a try-catch block then you don't really need the finally, these two blocks are almost always the same:
try { result = a/b } catch (exception) { //handle divide by 0 } finally { return result }

try { result = a/b } catch (exception) { //handle divide by 0 } return result

The difference is when you do something like this:

try { //do something that could throw an error return "something"; } catch(Exception ex) { return "something else"; } finally { //Always executes }

Business critical logic should always be done in transactions if you're trying to avoid only half of something being done.

2008-07-30 Reply Admin

Saaid:
Franz Kafka:
real_aardvark:
In a more realistic scenario, you'are asking an awful lot of the disk hardware. Let's assume that the db/OS in question conscientiously flushes through cache and RAM and paging system to the actual storage. What guarantee do you have that bits of your transaction log aren't stuck in the disk controller logic, and haven't yet reached metal oxide?

Flush() guarantees this. Of course, in the catastrophic case, that fails and you use backups. You can't be perfect, but you can get close.
Flush() is broken, then what do you do?

Install your DB on a different platform.

Technical Thug · 2008-07-30 Reply Admin

Franz Kafka:
Flush() guarantees this. Of course, in the catastrophic case, that fails and you use backups. You can't be perfect, but you can get close.

Flush() guarantees that you've pushed the data as far out as the OS can push it, but you still don't know where it's sitting. Is this an NFS connection? Are you inside a blade machine where all the blades are using each other's hard drives?

It's really hard to really make sure the bits are on metal without violating a whole big pile of abstraction barriers.

2008-07-30 Reply Admin

It depends on the language evidently because it doesn't with C#.

class Program { public static void Main(string[] args) {

		try
		{
			Console.WriteLine("Attempting to access property");
			int x = Number;
		}
		catch (Exception ex)
		{
			Console.WriteLine(ex.Message);
		}
		finally
		{
			Console.WriteLine("Finally block run");
		}
	}

	private static int Number
	{
		get { return Number; }
	}
}

Output

C:>TestApp.Console.exe Attempting to access property

Process is terminated due to StackOverflowException.

C:>

real_aardvark · 2008-07-30 Reply Admin

Jeff S:
real_aardvark:
Ah yes, the finally block: the goto of the modern world. An impression that many of the comments above reinforce.

Huh? So what are you saying? You believe that using Finally is a bad practice? I have no idea what correlation you are drawing between finally() and goto...

OK, the correlations:

(1) goto is generally deprecated. (1a) A better alternative to goto is almost always available. (1b) In severely restricted and well-controlled circumstances (see Torvalds and Linux Kernel), goto is still the best solution. (1c) In 99.999% of circumstances where goto is used, it is a mistake. It may represent bad design, sloppy code, lack of attention to future maintenance issues, general ignorance, or simply a desire to sabotage the project. In summary, in the vast preponderance of usages, using goto is a mistake.

I am now going to employ cut-n-paste -- another mistake, generally, but utilised here to emphasise my point. I promise you that the only change I will make is a simple substitution (well, two, because I'll lose the Torvalds analogy):

(2a) A better alternative to finally is almost always available. (2b) In severely restricted and well-controlled circumstances, finally is still the best solution. (2c) In 99.999% of circumstances where finally is used, it is a mistake. It may represent bad design, sloppy code, lack of attention to future maintenance issues, general ignorance, or simply a desire to sabotage the project. In summary, in the vast preponderance of usages, using finally is a mistake.

Counter-propositions welcome.

Use RAII instead. This even works, in the usual half-assed way, with languages that have garbage collectors.

2008-07-30 Reply Admin

My Tales:
Easy now. If that's how it works when the library re-throws, they're not really re-throwing, they're creating a new exception.
It sounds like you're using .NET, so you should use: try {...} catch (Exception) { ...; throw; }

Not: try {...} catch (Exception e) { ...; throw e; }

You are correct that it's bad form to throw (instead of rethrow) a caught exception, but you're incorrect in assuming that would change the exception type. The "custom" library must be doing:

try {...} catch (Exception e) { ...; throw new Exception(); }

I'd question, however, if the InnerException is properly set from the "custom" library. If so, I'd say they picked the wrong exception type to throw, but the original poster is making a mountain out of a molehill. If not, then yeah, that library should be dropped immediately.

2008-07-30 Reply Admin

If 100% data integrity all the time is your requirement, I wonder if you could store trx in a special non-volatile RAM board until a read from the disk verifies that the write worked?

2008-07-30 Reply Admin

Technical Thug:
Franz Kafka:
Flush() guarantees this. Of course, in the catastrophic case, that fails and you use backups. You can't be perfect, but you can get close.

Flush() guarantees that you've pushed the data as far out as the OS can push it, but you still don't know where it's sitting. Is this an NFS connection? Are you inside a blade machine where all the blades are using each other's hard drives?

You're a DB server. The redo log is not on an NFS server. It's on its own disk, probably.

/esse

2008-07-30 Reply Admin

real_aardvark:
Jeff S:
real_aardvark:
Ah yes, the finally block: the goto of the modern world. An impression that many of the comments above reinforce.

Huh? So what are you saying? You believe that using Finally is a bad practice? I have no idea what correlation you are drawing between finally() and goto...
OK, the correlations:

(1) goto is generally deprecated. (1a) A better alternative to goto is almost always available. (1b) In severely restricted and well-controlled circumstances (see Torvalds and Linux Kernel), goto is still the best solution. (1c) In 99.999% of circumstances where goto is used, it is a mistake. It may represent bad design, sloppy code, lack of attention to future maintenance issues, general ignorance, or simply a desire to sabotage the project. In summary, in the vast preponderance of usages, using goto is a mistake.

I am now going to employ cut-n-paste -- another mistake, generally, but utilised here to emphasise my point. I promise you that the only change I will make is a simple substitution (well, two, because I'll lose the Torvalds analogy):

(2a) A better alternative to finally is almost always available. (2b) In severely restricted and well-controlled circumstances, finally is still the best solution. (2c) In 99.999% of circumstances where finally is used, it is a mistake. It may represent bad design, sloppy code, lack of attention to future maintenance issues, general ignorance, or simply a desire to sabotage the project. In summary, in the vast preponderance of usages, using finally is a mistake.

Counter-propositions welcome.

Use RAII instead. This even works, in the usual half-assed way, with languages that have garbage collectors.

You're stating a bunch of opinions in a neatly-ordered list, not any real reasons to not use finally.

2008-07-30 Reply Admin

(2a) A better alternative to finally is almost always available.

Such as? The only one that comes to mind doesn't exist in most languages: desctructors and RAII.

(2c) In 99.999% of circumstances where finally is used, it is a mistake. It may represent bad design, sloppy code, lack of attention to future maintenance issues, general ignorance, or simply a desire to sabotage the project. In summary, in the vast preponderance of usages, using finally is a mistake.

Why? You have to back up an assertion like that (which was done for "goto").

2008-07-30 Reply Admin

BentFranklin:
If 100% data integrity all the time is your requirement, I wonder if you could store trx in a special non-volatile RAM board until a read from the disk verifies that the write worked?

Can't do that - reading from the disk goes through the block cache. 100% data integrity is usually a pipe dream, given most peoples' budget, so decide how much integrity you can afford and test your backups regularly.

2008-07-30 Reply Admin

real_aardvark:
Use RAII instead. This even works, in the usual half-assed way, with languages that have garbage collectors.

You can't do that with Java (maybe C#) because it doesn't support stack variables.

To the guy bitching about r_a's assertions, he's just lambasting the whole 'finally is a fancy goto' meme.

real_aardvark · 2008-07-30 Reply Admin

hamsandwich:
You're stating a bunch of opinions in a neatly-ordered list, not any real reasons to not use finally.

I'll save my breath and just shout at the top of my voice, then.

"In 99.999% of circumstances where finally is used, it is a mistake." (I mentioned this earlier, but I haven't scratched it against a windshield. It may very well not be a real reason. It's probably just fools' gold, like every second job I've done in the last eight years or so.)

I wasn't asked to give anybody a reason <not to> use finally. I was asked to justify the "correlation," or, as I would put it, "analogy," between goto and finally. Read between the lines. Indeed, read inside the lines. That was the intended purpose of the lists.

If you're lazy and stupid and only moderately capable of tying your own boot-laces on a good day, then, by all means, continue to use finally. (I don't much like continue, either.)

If you've seriously thought about the alternatives, and decided that they were worse options, then, by all means, be my guest.

The general alternative is to make sure you don't leave a resource or a state or a calculation dangling until you're pretty damn sure it's valid: but, hey, that's design, right? We're programmers, not designers. We just hack the thing about until blood stops spurting, and then we call it pizza nd eat it. (Mine's with extra anchovies. I miss female companionship since my mother died.)

If you've read all of the posts in this thread that make ludicrous claims about the use of finally, and you still think that it's the best option for you and for the four or thirteen or one hundred maintenance programmers who will follow on after you, then I'm truly happy to find somebody who actually thinks before he types the F-word.

It was two lists, btw. That's kind of how analogy with goto ought to work, imho.

You really, really, really want a simple answer? Here it is.

Practically anything that is done in a procedural language using a finally block should, in fact, be done during object clean-up. DRY, man, DRY. Also, do not force yourself to depend upon arbitrary cross-dependencies between objects (and here I include functions, if you want to deal with a fully first-class language), any or all of which may have side-effects.

Good enough for ya?

If you really, really, want my opinion on the one true reason not to use finally, except in extremis, then buckle up your basic C++ skills (it really doesn't take much, and a decent Java or C# programmer should be able to follow the argument through), and read Herb Sutter. There is no finally in C++. This doesn't make me think that C++ is an inherently better language than any other (far from it) -- but it does make me wonder what the fuck other languages really need a finally clause for.

Think again. Several times over, please.

There will be a pop quiz during recess.

real_aardvark · 2008-07-30 Reply Admin

anon:
(2a) A better alternative to finally is almost always available.

Such as? The only one that comes to mind doesn't exist in most languages: desctructors and RAII.

Gosh, I was unaware that languages other than C++ leave objects, memory, and other resources just dangling around until somebody hits the three-fingered salute.

That would, obviously, make "destructors" and "RAII" absolutely impossible to implement.

As opposed to, say, deterministically impossible to implement.

Addendum (2008-07-30 18:48):

anon:
(2a) A better alternative to finally is almost always available.

Such as? The only one that comes to mind doesn't exist in most languages: desctructors and RAII.

Gosh, I was unaware that languages other than C++ leave objects, memory, and other resources just dangling around until somebody hits the three-fingered salute.

That would, obviously, make "destructors" and "RAII" absolutely impossible to implement.

As opposed to, say, deterministically impossible to implement.

Note the qualifier "almost," incidentally. It's sort of like lazy evaluation in the case of garbage collectors: except that in their case it's more like lazy euthanasia.

2008-07-30 Reply Admin

Morasique:
Usually databases use journaling, so the change is logged in the journal before it actually happens. When the database starts, it checks the end of the journal to make sure it wasn't killed abnormally, and rolls back or commits whatever it needs to based on the journal to make the actual database consistent

Your database's journal file was corrupted by a catastrophic multiple drive head crash in your DB's raid array because of an earthquake. THEN, the power goes out in the middle of the transaction, from the same earthquake.

Now what does it do?

2008-07-30 Reply Admin

Sorry, this does not seem right. My understanding is that the list could contain a reference like a->next == a, in which case neither the slow nor the fast ever reach the end of the list, yet it contains a circular reference.

Oh, way to go Google interviewers.

2008-07-30 Reply Admin

Cannot speak about anything else than Oracle, but in the case of Oracle, you will be able to recover up to the last transaction ("redo") log you have a copy of. In Oracle you define the interval of the copies and the maximum size of your redo logs, so if you want to lose the least amount of data in the case of such a disaster, you'll probably define fairly small log files with very frequent flushes, better to off-size storage. Then you'll be able to recover up to the last of those saved logs. Of course, you pay a price in performance for running Oracle is this mode, but if you have such stringent data retention policies, you'll probably have the money to ensure them.

tgape · 2008-07-30 Reply Admin

Morasique:
BentFranklin:
Someone please educate me a bit: How does a database survive a power cycle in the middle of writing a transaction?
Captcha: appellatio (A program that sucks?)

Usually databases use journaling...

This is part of the answer, other posters have also given partial answers. For a more complete (and low-level, while still remaining generic) answer:

A good database will arrange its write operations such that the difference between having not entered the data and having fully and correctly entered the data is a single, atomic (meaning, it can't be interrupted by anything short of a hardware failure - and generally, even a power failure will allow it to complete) operation.

This is normally a very difficult task, especially if the database supports 'transactions'. Most modern databases use journalling, which makes it much easier (note: the below skips locking and parallelization, which would needlessly (because this isn't actual code) complicate the answer):

You write what you are going to do.
You update the journal end marker (a single, atomic update) to cover the new data.
You update the database data for all of the operations involved.
You update all the database indexes for the new data.
You update the journal start marker to not include that entry (a single, atomic update)

Now, there's two atomic updates there that have critical effects, rather than just one for a pre-journaling version. However, there's no need to dance around making dozens to hundreds of changes such that they don't take immediate effect until some later update occurs, because if it fails at any point after the journal is extended to cover the new update, the database will know exactly what it was trying to do, so can finish it up on restart. If it occurs before step two, then the operation never happened at all.

Of course, on error, there's also rollback, as others have mentioned. I think that's been adequately covered in other posts, however.

2008-07-30 Reply Admin

A real problem that prevent using finalize(The java almost destructor method) as raii for java, is that finalize is not run on application shutdown.

Why this matter, is that if you write to a file with a BufferedOutputStream and then stop the program then the content of the buffer will newer be flushed to the file, because the BufferedOutputStream is newer closed.

This is not a problem with raii in c++, because there the normal stack unwinding would cause all destructors to be called.

So relaying on the finalize method in java, to do needed cleanup and buffer flushing is not working. (Been there, done that, lost the data, patched the system, still looking for a reason that java don't run all finalize methods, when the cod reach the end of the normal Main method.

2008-07-30 Reply Admin

Hmmmm.

Reminds me of a Senior Visual C++ Developer who asked me in a whisper "how do I compile a program in Visual C++?".

2008-07-30 Reply Admin

Saaid:
Franz Kafka:
real_aardvark:
In a more realistic scenario, you'are asking an awful lot of the disk hardware. Let's assume that the db/OS in question conscientiously flushes through cache and RAM and paging system to the actual storage. What guarantee do you have that bits of your transaction log aren't stuck in the disk controller logic, and haven't yet reached metal oxide?

Flush() guarantees this. Of course, in the catastrophic case, that fails and you use backups. You can't be perfect, but you can get close.
Flush() is broken, then what do you do?

If the Flush() doesn't work, you call a plumber! I R A programmer now!

Leak · 2008-07-30 Reply Admin

AcidBlues:
Sorry, this does not seem right. My understanding is that the list could contain a reference like a->next == a, in which case neither the slow nor the fast ever reach the end of the list, yet it contains a circular reference.

You seem to be forgetting that the loop also terminates if both pointers point to the same object, which in this case will happen immediately, and at worst after two runs through the loop...

np: µ-Ziq - Goodbye, Goodbye (Royal Astronomy)

2008-07-30 Reply Admin

SomeCoder:
morry:
never put critical business transaction code in finally blocks.
I put all my absolutely critical business transaction code on a piece of paper, photograph it on a wooden table, then post that picture next to my computer. that way when the power goes out, I can execute the code myself.

where are you supposed to put the code? Magic fairy blocks?

That's what I was wondering. If you want a guarantee that your code will be executed... well I guess there are no guarantees. Don't use computers to execute business critical code?

I guess my point is, if the computer is suddenly shut off, it doesn't matter where your put your code*, finally or no. It's not going to be run if the machine is off.

*Note: I know it matters where you put business critical in an app but my point is, Alex was being a tiny bit pedantic in my opinion.

Perhaps a UPS or two would give the computer enough juice to complete the finally block?

As for pulling the plug. Really. Who has the god-like talent to cover every possible permutation of stupid?

tgape · 2008-07-30 Reply Admin

techie:
Not to be picky, but as someone who was promoted from tech support to programmer I've got a question. Did you actually ask any technical questions or are you just blindly assuming (like the wtf in your first example) that she didn't know how to program since she lied to get into the interview?

I'm a big proponent of using the tech support pool as a breeding ground for new developers. I believe that the biggest cost of outsourcing helpdesk services is that it generally loses this method of acquiring new developers.

That having been said, I would certainly not have hired Min - they weren't looking for a tech support person, but a developer. While the helpdesk does expose one to coding opportunities, and the best helpdesk workers will demonstrate a bit of coding expertise, which indicates they have developer potential, it does not strictly require coding capabilities.

The helpdesk is also a unique environment, in that it generally does not provide a required programming language - so the tech can learn whatever language they are most comfortable with, and knowing that also tells you something about what the person would be good at. Of course, I don't know this from personal experience, having never worked on a helpdesk. But I've worked with a lot of people who have (many of them while they were working on a helpdesk.)

In every programming environment I've worked in, there are always three things a new employee needs to learn: the culture, the management quirks, and the coding practices. Adding to this 'how to code', and 'how to better communicate with the rest of the team' is basically a non-starter. This was true even in the job where their requirements included "at least three programming languages - we don't care which ones". (Almost everything was written in a proprietary, in house language, which inherited concepts from C++, LiSP, Forth, ML, sed, awk, Ada, TCL, LPC, and COBOL. And that's just the ones I recognized.)

If the candidate does know how to program in at least one language, just not one that is relevant to your group, it's still probably a non-starter. If the candidate speaks the group's preferred language natively and knows how to code in a couple of non-relevant languages, that's getting close to something that might possibly work, but it's still a huge amount to pick up.

If I were interviewing Min, I would have continued the interview. If the company had an internal helpdesk, I probably would have recommended her for it. However, I would not have hired her myself. (If the company did not have an internal helpdesk, but she seemed like she had a lot of potential otherwise, I'd have recommended her to one of the various helpdesks I'm aware of.)

Note: the team I'm on at work consists of six people (including myself). Of those six people, only one has not worked on a helpdesk. He's the one with the most seniority on the team, and got a say in the hiring or selecting of everyone else on the team. So far, out of about 30 candidates considered, he's vetoed all but two of the candidates with no helpdesk background, and not vetoed any of the candidates with helpdesk background.)

Sutherlands · 2008-07-30 Reply Admin

AcidBlues:
Sorry, this does not seem right. My understanding is that the list could contain a reference like a->next == a, in which case neither the slow nor the fast ever reach the end of the list, yet it contains a circular reference.
Oh, way to go Google interviewers.

Yes, go Google interviewers, because you successfully weeded out someone who didn't realize that a circular list has no end.

Sutherlands · 2008-07-30 Reply Admin

real_aardvark:
hamsandwich:
You're stating a bunch of opinions in a neatly-ordered list, not any real reasons to not use finally.
I'll save my breath and just shout at the top of my voice, then.

Ignoring, for a moment, that fact that you just said you would save your breath by shouting, your post has no substance.

If someone made the following post:

A car is just like an orange: A car can transport people very quickly A car can be many colors A car has multiple seats
An orange can trasport people very quickly An orange can be many colors An orange has multiple seats

We wouldn't believe them, just like we didn't believe you. I can say "In 99.9999% of circumstances where static is used, it is a mistake." and then list off a bunch of hamball reasons why it's the same as goto, but that doesn't make it true. You're right that you were asked to justify the correlation, and yet, you failed to do that.

Then, you finally come back and repeat a bunch of stuff that doesn't make any sense, bolding words for no real reason, and try to pretend that you know more than everyone else. There are lots of things, like closing transactions, that should not be done in object cleanup. That would make absolutely no sense. When we come to your "one true reason" not use finally, you say because C++ doesn't have it? Wow, you sure know your stuff.

My Tales

Leave a comment on “My Tales”