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

[Jon Lambert]

Ola Fosheim Grøstad
> Hans-Henrik Staerfeldt wrote:

>> 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...  >

SQL is a 4th generation programming language and is algorithmically
non-predictive by design.  The speed of RDMSs has nothing to do with
the original issue of a high level languages determining an optimal
approach to solving a problem.  I think the example is an excellent
one.  You are perhaps taking the example literally though.  Don't
assume there is an RDBMS at all.  SQL can just as easily interface
to a file system, as well as an in-memory structures of some sort.
You can generate complex enough queries in SQL fast enough that it
would that take a prohibitively long time to design and optimize by
hand.  Then conditions change, someone modifies the query and your
optimized version is a total waste of bytes.  The point is the HLL
engine determines an optimal solution to what is essentially a
dynamic problem.

Besides, IIRC, haven't you argued in the past _for_ a mud design
that supported non-predictive, open and undefined user actions!!!

It's obvious, at least to me, that such a beast, if ever written,
would have to sport a smart high-level or abstract "language" of
some sort.  I'm thinking "runtime polymorphically generic or
parametric", unless someone can come up with some more accurate
terminology.

--
--* Jon A. Lambert - TychoMUD        Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev