Have you hugged your computer today?
Computers absolutely hate it when you anthropomorphize them.
Murphy's law 1: There's always one more bug.
Murphy's law 2: When the computer fails the part that fails first will be the most expensive and least accessible.
There are a lot more of Murphy's sayings here.
Q. Why can't programmers tell the difference between Haloween and Christmas?
A. Because 31 Oct = 25 Dec
Speaking of Christmas, the following is self-explanatory
Two Christian software engineers were very close friends and had worked together as a team for many years. They made a pact that whoever died first would ask the Lord for permission to come back and tell the other one what heaven was like. In the course of time, one of them did pass on to the next life. True to her word, she appeared in her friend's study two nights later. In view of their deal, Patsy (the living one) was not too surprised to see her friend.
"Sally," she said, "Thanks for coming. I'd give you a hug and offer you some pizza, but..." There was a brief silence, then, "So tell me about heaven."
"Shucks, Patsy. It's terrific, but there's good news and bad news."
"I'll take the good first."
"We've got the best computers you can imagine in heaven, Patsy. They're Macs. Engineers take all the time they want with planning and documentation, and the finished products never have bugs. Its fantastic!"
"And the bad..."
"Hey, Patsy. We're starting you on a dynamite project in the morning."
A Software Engineer, a Hardware Engineer and a Departmental Manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt, scraping along the mountainside. The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?
"I know", said the Departmental Manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals, and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."
"No, no", said the Hardware Engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it, and we can be on our way."
"Well", said the Software Engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again."
'Twas the night before release date and all through the house,
not a program was working, not even a browse.
The programmers hung by their cubes in despair,
with hopes that a miracle soon would be there.
The users were nestled all snug in their beds,
while visions of working code danced in their heads.
When out in the lobby there arose such a clatter,
I sprang from my desk to see what was the matter.
And what to my wondering eyes did appear,
But Super Programmer with pizza and root beer.
His resume glowed with experience so rare,
he turned out great code with a bit pusher's flair.
More rapid than eagles, his programmes they came,
and he whistled and shouted and called them by name.
On Menu, On Report, On Procedures And Delete,
On Monitor, On Batch jobs, On Dialogues complete.
His eyes were glazed over, fingers nimble and lean,
from weekends and nights spent in front of a screen.
A wink of his eye and a twist of his head,
soon made it clear we had nothing to dread.
He spoke not a word, but went straight to his work
turning specs into code; then he turned with a jerk;
And laying his finger on the <enter> key
the software came up and worked perfectly.
The menus they menued, the deletes they deleted,
the reports they reported, and the batch jobs completed.
He tested each whistle, and tested each bell,
with nary a stack dump, and all had gone well.
The software was finished, the tests were concluded
Our users' last minute requests were included.
They the users exclaimed with a snarl and a taunt,
IT'S JUST WHAT WE ASKED FOR BUT NOT WHAT WE WANT!
Here's a good way to illustrate the concept of an infinite loop, though getting students to cooperate is not easy. They tend to get lost.
Support Desk I
"Ridge Hall computer assistant; may I help you?"
"Yes, well, I'm having trouble with WordPerfect."
"What sort of trouble?"
"Well, I was just typing along, and all of a sudden the words went away."
"Hmm. So what does your screen look like now?"
"It's blank; it won't accept anything when I type."
"Are you still in WordPerfect, or did you get out?"
"How do I tell?"
"Can you see the C:\ prompt on the screen?"
"What's a sea-prompt?"
"Never mind. Can you move the cursor around on the screen?"
"There isn't any cursor: I told you, it won't accept anything I type."
"Does your monitor have a power indicator?"
"What's a monitor?"
"It's the thing with the screen on it that looks like a TV. Does it have a little light that tells you when it's on?"
"I don't know."
"Well, then look on the back of the monitor and find where the power cord goes into it. Can you see that?"
"Yes, I think so."
"Great! Follow the cord to the plug, and tell me if it's plugged into the wall."
...."Yes, it is."
"When you were behind the monitor, did you notice that there were two cables plugged into the back of it, not just one?"
"Well, there are. I need you to look back there again and find the other cable."
...."Okay, here it is."
"Follow it for me, and tell me if it's plugged securely into the back of your computer."
"I can't reach."
"Uh huh. Well, can you see if it is?"
"Even if you maybe put your knee on something and lean way over?"
"Oh, it's not because I don't have the right angle - it's because it's dark."
"Yes - the office light is off, and the only light I have is coming in from the window."
"Well, turn on the office light then."
"No? Why not?"
"Because there's a power outage."
"A power... A power outage? Aha! Okay, we've got it licked now. Do you still have the boxes and manuals and packing stuff your computer came in?"
"Well, yes, I keep them in the closet."
"Good! Go get them, and unplug your system and pack it up just like it was when you got it. Then take it back to the store you bought it from."
"Really? Is it that bad?"
"Yes, I'm afraid it is."
"Well, all right then, I suppose. What do I tell then?"
"Tell them you're too STUPID to own a computer!"
Support Desk II
An unfailingly polite lady called to ask for help with a Windows installation that had gone terribly wrong.
Customer: "I brought my Windows disks from work to install them on my home computer."
Training stresses that we are "not the Software Police," so I let the little act of piracy slide.
Tech Support: "Umm-hmm. What happened?"
Customer: "As I put each disk in it turns out they weren't initialized."
Tech Support: "Do you remember the message exactly, ma'am?"
Customer: (proudly) "I wrote it down. 'This is not a Macintosh disk. Would you like to initialize it?'"
Tech Support: "Er, what happened next?"
Customer: "After they were initialized, all the disks appeared to be blank.
"And now I brought them back to work, and I can't read them in the A: drive; the PC wants to format them. And this is our only set of Windows disks for the whole office. Did I do something wrong?"
Many students have trouble with the need for temporary memory for the purpose of conducting a swap. You can't just say:
alie := 5;
blie := 6;
alie := blie;
blie := alie;
because the assignment of blie to alie wipes out the original value of alie, and in the end, both variables have the value 20. What you need to make this work is a temporary variable to hold the value of alie, so it is not lost. Thus, the code is written:
alie := 5;
blie := 6;
templie := alie;
alie := blie;
blie := templie;
The reader should check (trace) this to ensure that this code really does swap lies correctly. However, what if, say for security reasons, you don't want to have a temporary variable (or you have to zero it out afterwards). Is it possible to do the swap without using any extra memory? Yes, if you have an exclusive-or operation available, and write the code this way (traced using binary values):
alie := 5; (* binary 101 *)
blie := 6; (* binary 110 *)
alie := alie xor blie; (* alie holds 011, blie still has 110 *)
blie := alie xor blie; (* alie still holds 011, blie is now 101, as desired *)
alie := alie xor blie; (* alie is now 110=6, b is still 101=5 *)
and the swapping of lies is successful, using the same number of statements as the original, but no extra memory. Thanks to Nathan Sutcliffe for pointing this out.
Like what you see? Want to exchange links? Want to contribute original or attributed material? Contact Us. If We use your material, We'll acknowledge the source.