Caching Considered Harmful

Note: Ronald Reagan used to tell the story of the little boy who thought he was going to get a pony for Christmas. Christmas morning came, however, and there was no pony in his yard...only a pile of horse manure.

His Mom found him shoveling furiously at the pile of horseshit, and asked him what he was doing. He said, "Mom, there's a pony in here somewhere!"

The "pony" in this article is a tech suggestion. It's at the end of a broader social analysis of why caching can be harmful.

"If you can cache it then do it".

Wrong, I am afraid.

It does seem to be an nifty and expert programming gesture, to cleverly put some information someplace where it can be read faster.

And, the cache and the "lookaside" has had a long and honorable history.

However, caution is in order.

An old IWW (Industrial Workers of the World) cartoon has Moe talking to John Q. Citizen: Moe is, in the old cartoon, a wised-up Marxist regular guy while John Q. Citizen is a schnook, overinvested in the capitalist order.

John Q. Citizen says, "say, pard, dose strikers sure are bums, closin' down our factories". To which Moe says, "YOUR factories, chump? You don't even own da smoke!".

In caching, the programmer decides to use "his" storage, such as the common region in a non-stateless object, for a lookaside buffer. He forgets the social logic of code, which is that the programmer, as an agent of the firm, has in fact no title to the storage on his company's servers.

Which means that the company, often uninformed of the lookaside buffer use in documentation, will assume that the completed code can be moved at-will to a new software and hardware environment, in which the storage previously used may in fact disappear, or its use lower performance.

Basically, stateless objects, like the ideal employee in a bad company, don't have a memory. Ideally, the company's long term and short term memory would be COMPLETELY resident in documented Oracle or SQL Server data bases, and this would include temporary storage!

This I admit is harsh. It demands that programmers code "pure procedures" because in fact, code with hard coded constants, "tables" of "codes", and secret scratchpads place the companies systems in states at variance with The Grand Plan.

I'm serious about this, by the way. I'm neither judging the programmer whose creativity in facts asserts ownership over some part of the company's computing space...nor the company which is in fact driven by the remorseless logic of the capitalist system to ever-sharpen its ownership bigod RIGHTs.

This tends the corporate system in the direction of an ideal: the software system, based on a normalized data base, that consists exclusively of stateless enforcement of strictly business rules.

In this pitiless vision, there is no place for malarkey in the form of a "cache" that makes "processing" more "efficient" in the current configuration, because it is in fact an item of management faith that programmers don't know what will happen next, because they ain't gonna tell them.

The remorselessly Teutonic theorist Peter Drucker (who at the end of the day saw the limitations of capitalism in the way it is failing even the American midlevel) took it as an article of faith the fact that management doesn't own just physical plant and machinery. In Drucker, its ownership is hegemonic and extends not only to software (whose ownership by the firm was asserted in the actual application of structured programming theory) but also to "culture" and memory itself.

[Did you ever get the feeling that the free M & Ms, the beer blasts, the false camaraderie, the loose and free and easy corporate culture were missing at the critical point, eg., that it wasn't necessarily the sort of culture you and your mates would come up with?]

[What exactly does it mean for one to grow up in an era in which your culture, including dat old Debbil music, has been resold to you, and in which you "may" become a computer nerd when you really wanted to be a cross-dressing lumberjack?]

[I works all night and I sleeps all day...]

[And, if Adorno was right about "the conquest of the thing represented by its representation", why then we may reinterpret today's world as the replacement of genuine choice by a range of disavowed images of Dionysian freedom, which sour and surfeit REAL people into a frozen hatred of Calvin Klein: real people become a crowd of peasants with pitchforks and torches who know only what they hate, be it Hungarian notation or Paris Hilton, because they, the thing represented, no longer exist, whether as Real Programmers or anything else.]

[I likes to pick wild flowers...]

[Are we not men?]

This hegemonic ownership of culture and memory of course creates a contradiction. There's no such thing as non-human memory, only artifacts such as RAM which demand a constant human interpretation to be anything other than toxic waste.

Therefore, programmers are forced to play passive-aggressive games to preserve a memory that is taken from them, simply to do an effective job in the first place.

In fact, Joe Programmer has to cache things on the client! He has to write client side code!

But practically speaking, formatting a cache is a risk to "your" firm; Moe, in my IWW story, failed not only to realize that actually existing socialism would suck (since he and Joe Hill failed to survive America's entry into WWI, the persecution of the German-American left, and the Palmer raids) he also fails to realize that in Arthur Miller's words, in Death of a Salesman, "nobody dast blame" John Q. Citizen.

White collar people do indeed assert ownership of the tools of production, for example by clever programming which uses resources to save more resources (a micro-investment gesture reserved in the official discourse to the godlike entrepreneur) because they have to support their families.

I'll wrap up with a tech recommendation. Like I said above, there's a pony in here somewhere.

If it appears to you that your class needs "state", such as a cache, consider splitting the class code into a stateless procedure with no memory, and an "amulet", a small stateful class that contains, on behalf of specific uses of your class, the cached information, and make the amulet an old fashioned parameter.

I'm re-engineering the utilities.DLL of Build Your Own .Net Language and Compiler and I've realized that a drawback of the old VB version, which I am recoding in C sharp, was that its basic "item" parser had no memory.

When presented several times with the same string for parse, the old version would always parse from the left.

In the old VB 4 era I'd coded a powerString as a stateful parser with a cache and was terribly proud of myself.

However, this imposed on the powerString user the burden of calling a largeish object with state...she had no choice.

I've decided to restore caching to the C Sharp version of utilities.DLL, but as a choice. The user shall be permitted to pass an optional overload parameter, a parseInfo class instance, and this magic amulet will contain old parse info!

The decision, to have state, is higher up and it is in the caller. If she creates an amulet by means of one call, she may optimize subsequent calls.

In a way, this reminds me of coding before "stacks", assembler language on the IBM 360, for here, callers of subroutines had to pass a place for the subroutine to save the registers.

Nonetheless it seems a progressive step because it factors simple, repetitive, mindless parsing versus parsing with a memory that can parse long strings.

Cache-ers of the world unite! And do it right!