Coyote Rule #3

by woodsps56 on 10-11-2010 03:25 PM - last edited on 10-12-2010 10:24 PM

Ok, I've known about the coyote rules for some time now, and I always knew they’d come in handy. How  appropriate for the first blog I’ve posted in months. I’ve been busy, and we all know there’s good busy and bad busy. I’ve come full circle through each several times, but now I’m actually getting emails and comments on posts that I made when I first entered my good busy phase. In my good busy phase I was scheming to trap the road runner. Getting all sorts of deliveries from Acme (Books from Amazon/Tools from Open Source), building all sorts of road runner traps (algorithms), and finding myself looking up as anvils crashed down on my head (functional programming).

 

 Coyote.jpg 

 

Source: http://en.wikipedia.org/wiki/Wile_E._Coyote_and_Road_Runner

 

I felt much like my old friend  Wile E. Coyote, so much so I Goggled ole Wile to see if he could offer any advice. I found the coyote rules.

 

  1. Road Runner cannot harm the Coyote except by going "beep, beep."
  2. No outside force can harm the Coyote—only his own ineptitude or the failure of Acme products. Trains and trucks were the exception from time to time.
  3. The Coyote could stop anytime—IF he were not a fanatic. (Repeat: "A fanatic is one who redoubles his effort when he has forgotten his aim." —George Santayana).
  4. No dialogue ever, except "beep, beep" and yowling in pain.
  5. Road Runner must stay on the road—for no other reason than that he's a roadrunner.
  6. All action must be confined to the natural environment of the two characters—the southwest American desert.
  7. All tools, weapons, or mechanical conveniences must be obtained from the Acme Corporation.
  8. Whenever possible, make gravity the Coyote's greatest enemy.
  9. The Coyote is always more humiliated than harmed by his failures.
  10. The audience's sympathy must remain with the Coyote.
  11. The Coyote is not allowed to catch the road runner.

As many of you may be programmers, you will no doubt relate to several of the above rules, but rule three describes my now months long dive into functional programming in Scala. I’ve gotten emails about this and since I’ve only mentioned it here, I hope someone is reading.

 

The good news, we’ve gotten a version of my legacy cloned code algorithm working, but the gravity (performance problem) is still my greatest enemy. I’m going to have to use some imperative programming, I’m afraid. I’m counting on rule number 10.

 

Look for my standard weekly posts to restart on legacy source code analysis on the an my other blog.

 

http://h30507.www3.hp.com/t5/Talk-to-the-Modernization/bg-p/659

 

This is the only post that will be duplicate.

 

We encourage you to share your comments on this post. Comments are moderated and will be reviewed and posted as promptly as possible during regular business hours.

To ensure your comment is published, please follow our community guidelines.

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.

Find HP in Social Media

Facebook Twitter YouTube SlideShare Flickr
About the Author
Latest Comments