[Tfug] Cheap Memory = Lardy Men.

[bpoag at comcast.net]

Hi Rob,

Faster, better, cheaper = bad? 'course not. Fast hardware is a good thing, but NOT if it comes at the expense of making lazy-ass coders or sets the stage for the fat man in the house, imho. Lets call the fat man in the house "Hambone". :)

It's just a pet peeve/wish of mine, that coders would incorporate some measure of big-picture thinking when it comes to their work. I've always tried to keep my code as compact, self-reliant, and efficient as possible.. At least as best as I know how to at the time. I'm far from perfect,  but thats what I shoot for. If I didn't, one thing will lead to another, and before I know it, i'll have a Hambone on my hands, and he'll be laying there scratching his itches with a deep-fried turkey leg, and the fire department is on the way with a chainsaw ready to cut a hole in the side of Hambone's house. Thats a problem. A big, stinky, scratching-his-itch-with-a-deep-fried-turkey-leg problem.

* Disclaimer * : I don't want everyone in the world to code like me. I suck strongly on occasion..The drop in atmospheric pressure is enormous. Sometimes, the weather guy from a nearby TV station calls asking what the hell is going on, and if i'm coding again.  But at least, at LEAST try to pay some mind to what you're doing in the grand scope of things..The world is full of programs that began as small, lightweight, flexible, ridiculously fast code.. only to have layer after layer after layer of bloat slapped onto it like bacon on a hotdog to the point where the core of what made it so good to begin with is practically unrecognizable. Then you have a Hambone on your hands, and he's hungry, and he ain't moving. :)

A simple, microcosmic case in point:

I've got a co-worker (Hi Paul) who decided to rewrite a simple Perl script of mine that manages storage on AIX boxes. The purpose of the script was to act as a live monitor for a file system, and slowly add space to the corresponding logical volume as the filesystem grows, making sure the filesystem never runs out of space. It has a few clever options, like being able to fire off an email every X number of times it adds space to remind the owner that it's still busy behind the scenes, a variable check frequency, logging ability, variable increment size, and it'll even preserve X amount of space in the parent volume group rather than continue and fully deplete it. It'll even tell you if it's hands are tied and can't do it's job any longer. Not too hard, right?

My original version weighed in at 5.7KB total...It has one dependency, a common one (Mail::Sendmail), and a 1.8MB memory footprint when running.

Paul and I decide to rewrite it, to make it more daemon-like versus tool-like. The new spec that calls for a configuration file to be used. Again, no big deal, right? Shouldn't take much to add that functionality to it...

I rewrite my script.  

The addition of a config file parser makes my script grow to 9.7KB. Still one dependency, and the same memory footprint, 1.8MB.
Thats a size increase of 59%, and a 0% increase in memory footprint.

Paul's version, built from scratch, weighs in at 43KB, has three separate dependencies, and a memory footprint of 2.9MB.
Thats a 754% increase in size , and a 61% increase in memory footprint. 

Yes, I know that sizes like these are just piss in a bucket on modern systems --  Hell, less than piss in a bucket. But what i'm getting at here is the design philosophy that underpins the task of improving a program is what should matter, imho.

Paul IS a great coder (believe me),  and certainly more skilled than me, but his approach is very different than mine. He has no qualms about introducing dependencies, hampering his ability to write portable code, and dragging in every 800 lbs gorilla he can find to perform simple tasks---because that's his approach. Thats his philosophy.  He builds so that it's (hopefully) easy on the programmer. I build so that it's easy on the machine. Paul's style, while not Hambone-producing in and of itself, allows for a Hambone to eventually exist. My style does not.

The net result is, if I die in a horrible whip-cream related accident, or get abducted by hot, hot aliens or something, someone is going to have to sift through that 43KB worth of code when they only really needed to sift through 9.7KB.  The time it would take to unravel Paul's 13 subroutines and 8 separate (linked!) hashes, you might as well just make your own version. Why not avoid that if you can? Why not have a straightforward design, that uses only 3 subroutines, and a single well-designed hash?

As I see it, you, as a programmer, should not make an effort to feed Hambone. Hambone doesn't need any more tacos. Do not buy Hambone two buckets of KFC every day, or one. Buy him zero. Do not give Hambone gravy, nor give Hambone a single Ho-Ho or Twinkie, because you DON'T want to have to cut the side of his house open and haul his ass out of it when it's time to upgrade his feature set. It stinks, and it sucks.

Cheers,
Bowie


 -------------- Original message ----------------------
From: Robert Hunter <hunter at tfug.org>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, Dec 17, 2007 at 08:28:41PM -0700, Bowie J. Poag wrote:
> > 
> > Good news is, if Moore's Law begins to break down, more people will 
> > realize they're cutting holes in fat men's houses. The solution isn't to 
> > cut holes in the sides of buildings, or build a bigger houses for fatter 
> > and fatter men. The solution is to keep the fried chicken away from the 
> > fat man in the first place.
> 
> Hehe.  So, what is the final message here, Bowie?  We should all run
> Pentium 75s with 16MiB of RAM?  Write software in assembly with line
> editors?  Debuggers --  bah!  Those are for pussies! ;-)
> 
> OK, you do have one point, which might be phrased as "necessity is
> the mother of invention."  So, sometimes when people are faced with a
> constraint, they will come up with an ingenious solution.
> 
> On the other hand, you are assuming optimization criteria which might
> not always apply, such as "you must complete this task in the least
> possible amount of memory."  Also, you seem to imply that an algorithm
> which is optimized for memory use, will also have optimal time
> complexity.  This is often not the case.  Ever hear of time-space
> trade-offs?
> 
> Optimization criteria might also include labor and training costs.
> For instance, would you write a data-mining tool in C, or assembly?
> Probably not.  You might instead use a slow, memory-hogging, scripting
> language which is very good at text processing (e.g., Perl).
> 
> Moral of the story?  Use the right tool for the job.  It helps to keep
> an open mind. ;-)
> 
> - -- 
> Rob
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFHZ9dpJ1pz6tWxufARAjzEAJ0SAMkkxDvqnnmwd8aTh42d6m7jhwCcDTcj
> /VOWpbr8nTYEyp8IOnfVcnA=
> =h8q2
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org