The Lazy Moose - Part 01 of 03

When Laziness is a Virtue - Part 01 of 03

Target Audience: This series is pitched at developers interested in Object Oriented Design Patterns using the Moose framework in Perl.

There are times when laziness is a virtue. There are places where when hubris is laudable. The time has come and let me show you the place.

Remember attributes? This whole piece centers around two attributes - lazy and default. Specifically, lazy-loading - which is when data magically appears when requested, and not until then. The default attribute supplies the magic wand that produces data.

Why is this useful? Suppose one has a chain of events arranged whereby a few high-level events recruit many middle-level events which in turn recruit myriad low-level events in order to achieve a high-level objective. Sort of like feudal Japan where the peasantry bowed to Samurai (Warrior Class) and Samurai bowed to Daimyo (Knights) and Daimyo to bigger Daimyo (Lords) who all bowed to the Shogun (Dictator) - who sometimes put the dick in dictator but more often than not, was a highly skilled leader and administrator. Can you think of such a hierarchy in the computational world, where low-level functions harvest information from databases or web-services and supply them on-request to pre-processors which in turn pass up clean, formatted data to persnickety middle-level processing functions that successively distill value until something interesting and useful comes out at the very top?

Ordinarily, such an application is designed as a 'push' system where data is pushed from one level to the next. Since the system has no way of knowing what will be requested next, it can only push information upwards until pre-fabricated goods sit on the shelves waiting to be picked off - whether required immediately or not. An "all or nothing" approach.

That is not an enlightened way to go about it. Would it not be better if components could be fabricated on demand - only when required? A 'pull' system where, once fabricated, a component remains available for the next request. What's not available is filled-in only when a request comes in.

Come to think of it, this is not unlike a "Just In Time" system for computer applications. Watch, how laziness becomes virtue.

The example I have chosen is a pragmatic one of Earned Value Analysis - a technique deployed by professional project managers for Monitoring and Control. It consists of three entities:
EV - Earned Value, representing how much value is earned from effort expended to-date.
PV - Planned Value, representing how much value the project planners thought would be earned to-date.
AC - Actual Costs, representing how much money has actually been spent to-date to generate the EV.

This helps monitor the project in terms of -
- Schedule Performance Index (SPI) - how we doin on time (baby)?
- Cost Performance Index (CPI) - how we doin on cost (dude)?

And the rest of this fascinating story of time, costs, sexual escapades, intrigue and as many as three of the 7 deadly sins unfolds in Part 2.

All code in this series may be downloaded from:
http://sites.google.com/site/sanjaybhatikar/codeunquote/designpatterns-1