Re^4: Hash space/ time tradeoff

in reply to Re^3: Hash space/ time tradeoff
in thread Hash space/ time tradeoff

So, pick your battles and don't sweat the small stuff.

You write some garbage that's "fast enough" for you, then the next guy writes some garbage on top of yours that's "fast enough" to collect his paycheck, etc. Eventually some poor schlub has a program that runs forever, benchmarks it to find a flat profile, tries to fix your stuff, and finds layer on layer of "good enough" design.

If you think a bit and write something decent, other people will be able to reuse your code. However, if you generate garbage, some poor fool will just have to rewrite it later. "Whatever you thought of first" and "whatever seems clear to you" are not necessarily decent.

Comment on Re^4: Hash space/ time tradeoff

Replies are listed 'Best First'.
Re^5: Hash space/ time tradeoff by GrandFather (Saint) on Dec 28, 2013 at 08:41 UTC
I agree - think a bit and write something decent, but in the words of Scotty: "The more they overthink the plumbing, the easier it is to stop up the drain". You are conflating good overall design with sweating the small stuff. If the overall design is good then the problematic bottle neck code can easily be identified by the schlub and fixed in isolation from the rest of the code, especially if there is a good suite of unit tests for the code. Any army that puts itself in a position of depending on a single nail for success is doomed to failure. Bending an initial design to anticipate future problems most likely wastes time now and probably doesn't help with the unforeseen problems that actually arise in the future. Anticipating a missing nail or any other single detail is hard and time consuming. Ensuring there are sufficient blacksmiths available is easier, prevents the issue and allows a better design of nail to be adopted in the future if required. True laziness is hard work	[reply]

Replies are listed 'Best First'.

Re^5: Hash space/ time tradeoff
by GrandFather (Saint) on Dec 28, 2013 at 08:41 UTC

I agree - think a bit and write something decent, but in the words of Scotty: "The more they overthink the plumbing, the easier it is to stop up the drain".

You are conflating good overall design with sweating the small stuff. If the overall design is good then the problematic bottle neck code can easily be identified by the schlub and fixed in isolation from the rest of the code, especially if there is a good suite of unit tests for the code.

Any army that puts itself in a position of depending on a single nail for success is doomed to failure. Bending an initial design to anticipate future problems most likely wastes time now and probably doesn't help with the unforeseen problems that actually arise in the future. Anticipating a missing nail or any other single detail is hard and time consuming. Ensuring there are sufficient blacksmiths available is easier, prevents the issue and allows a better design of nail to be adopted in the future if required.

True laziness is hard work

[reply]

In Section Seekers of Perl Wisdom