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

Bobby Martin bobbymartin at hotmail.com
Sun Sep 2 19:48:09 CEST 2001


> From: Hans-Henrik Staerfeldt <hhs at cbs.dtu.dk> 
> On Thu, 23 Aug 2001, Ola Fosheim Grøstad wrote:
 
[attribution lost somewhere along the thread]

>>>  This is exactly what makes high-level languages potentially
>>>  fast: the compiler can take your high-level specification,
>>>  figure out what it is that you're actually trying to do, and
>>>  apply an algorithm to solving it that is more efficient than
>>>  anything you could ever have come up with on your own, because
>>>  it takes advantage of years of research on a topic you may
>>>  never have even heard of.
 
>>  Potentially maybe.  Unfortunately, I can't even see how this
>>  could be generally achieved even in the most theoretical sense.
 
> 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.

This also happens every time you use a hash or tree map.  The
programmer has a desire: when I get X key, I want to be able to
quickly look up Y value.  Using a map implementation in STL, Java,
or Perl to do this is trivial and very efficient: even the neophyte
programmer can do it.  However, if those programmers implemented the
algorithm themselves; say, in assembly; they would likely use a
brute force "look at each key/value pair and see which one matches"
approach.

There are all kinds of super-efficient algorithms and structures
that advanced research has produced and then refined to a trivial
interface, and which we use all the time without thinking about it.
Isn't this precisely the same as the 4GL example under discussion?

Regards,
Bobby Martin
Cosm Development Team

secure email: bobbymartin at hushmail.com
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list