[MUD-Dev] TECH: programming languages (was: Re: TECH: STL / Heaps, etc.)

Adam Martin ya_hoo_com at yahoo.com
Wed Sep 5 10:38:07 New Zealand Standard Time 2001

----- Original Message -----
From: "Ola Fosheim Grøstad" <olag at ifi.uio.no>

>> An example is database searches; here your SQL query is analyzed,
>> and the database search engine makes a number of strategies for
>> evaluationg your query. It will the try to select the fastest
>> strategy. Sure this does nothing for very trivial searches, like
>> getting all players named "John", but for more complex searches,
>> like getting the the top 10 items based on weight that is named
>> "Cup", it makes sense first to select the items named cup and
>> then sort them, rather than sorting all items and then select for
>> cup. I don't know about the 'designing an algorithm' part, as i
>> don't see anything alike 'agorithm design' here, but in some
>> limited way it is already being done.

> Hmmm... Well, I don't agree in the general sense. Relational
> databases are slow by nature compared to the optimized alternative
> for a particular task. (You surely don't want to throw out your
> filesystem?)  However, I could agree with you to some extent if
> the application involves user-generated queries and they tend to
> be unpredictable, but then we are not really talking about
> programming...  

Surely the biggest usability problem with filing systems from the
users point of view is not being able to very quickly make general
queries with advanced matching etc? The very first thing I want them
to do to my OS of choice is replace the FS with a DB (MS is about to
do this for windows, and with linux I'm just waiting till I have
enough time to evaluate alternatives). Don't *you* get fed up with
having to remember where you saved things, seeing as doing that work
for you is a typical computer-type-task rather than anything that
requires human intervention?  Recall that folders on an FS are there
originally to help the computer, not the user.

The statement that DBs are slow compared to the optimized
alternative seems a bit pointless. I can counter with saying that
most calculators are slow compared to having a database of
calculations and answers, which could return an answer much faster
than a calculator could, say, integrate a given equation, or
calculate PI to 10000 places. Doesn't mean you'd ever want to
implement such a calculator, except where the data size is
absolutely tiny (pre-calced lookup tables are the best example I can
think of).

Adam M
MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list