Re: sparse components

I think that was my quote! (:

Anyways, one reason why you're probably finding inspiration in older tech (SQL) is that back then the SQL optimizations were quite hardcore, dealing with insanely slow external storage and limited memory. (Just like slow main memory and limited caches.)

MSN
From: [email protected] [mailto:[email protected]] On Behalf Of Richard Fabian
Sent: Tuesday, June 01, 2010 2:37 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] sparse components


On 29 May 2010 07:09, James Hofmann <[email protected]<mailto:[email protected]>> wrote:
In fact, by minimizing the potential for bugs, via reducing API surface area or enforcing structure or adding abstraction mechanisms that directly reflect the intent the client wants to accomplish, increases the magnitude of optimizations you can make.

Going the opposite way, that is, providing generic solutions to hard problems that don't reduce complexity, makes it harder to do both.

This is my experience exactly, and it seems to hold true throughout software development. It's really, really easy to think you have "The Answer" to making some slippery problem generic, whether it be a generic tool, data format, architecture paradigm, data structure, language feature, etc. Then you try it and it blows up in your face, while the simple naive solution works and lets you get on with the real problems. You know you have some great, reusable code going when it's utterly boring and trivial to think about.


Yes, OO has finally blown up, you're right. The old fashioned ways did turn out to be boring and correct! Which is why I'm using them as both source of inspiration and a source of validation of any findings.

--
fabs();
Just because the world is full of people that think just like you, doesn't mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com