This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Caching is not agile Feed Title: Michael Lucas-Smith Feed URL: http://www.michaellucassmith.com/site.atom Feed Description: Smalltalk and my misinterpretations of life Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Michael Lucas-Smith

One thing you'll hear programming experts say over and over again is that premature optimisation is bad. Why? Why is it so bad. Is it because it's harder to change the code? If that's the reason then you're frelled as soon as you decide you're not being premature any more.

That basically sums it up - you never want to optimise? Well, it depends on the kind of optimisation you're doing. If you decide to use instance variables to cache values so that you don't have to recalculate them, then yes, you're going to have trouble.

Nonsense you say! Well I'll be happy to argue this one out with you. As soon as you decide to cache a value, you'll suddenly need to know all its dependencies, not only who calls it when but what conditions can change it. And conditions that set in motion other conditions that can change it, etc..

Even debugging can cause your value to be instantiated at a bad moment which will suddenly make your program run one way, not the way you were trying to debug.

Is there a solution to this? Well, certainly. Firstly, you can optimise your program by changing algorithms. An algorithm is a design decision, not an optimisation trick. Secondly, you might consider using a programming language that will cache values for you. Functional programming languages do this by knowing what causes side-effects and what doesn't.

Could the later approach be adopted in Smalltalk? Well, it depends. If you went down the side effects path you quickly realise that you must look at the state of all instance variables, and potentially their state, to ensure that you have enough context to state that the cached answer you will return is the correct one.

The alternative is to give the system hints as to what instance variables matter - but this will take us right back to the caching problem.

Any one have any smart ideas on adding a meta-facility to Smalltalk for caching optimisations, so that programmers don't polute their programs with premature optimisations?