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

[Kwon Ekstrom]

From: "Jon Lambert" <tychomud at ix.netcom.com>

> 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

RDBMS is more of an example of using an implementation as a time
saving tool... They're not as efficient as a solution specifically
designed to fit the problem, but are good enough to do the job and
are more portable via a common interface (SQL).  In some cases due
to time constraints and the relatively "good" performance of an
RDBMS at maintaining large data stores, they make a good overall
data store.

> 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

*nod* but using your example as an interface to a non RDBMS you
would have to design your own implementation which would most likely
take longer and thus negate your development time savings.  Of
course that's not your point... Often a high level language will
contain libraries that you can extend to quickly develop a solution.
In java you have a collections API, which has several storage
objects predefined (someone mentioned Hashtable in a previous post).

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

I agree that a high level language can have a performance advantage
over a low end language, in fact I think that it's a regular
occurance.  The problem with it is, the programmer must know what
the language does well and what it doesn't.  You could easily negate
your performance gains in one area by using features that aren't as
well supported in another.  Or by misusing a feature.

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

Sounds similar to the filtering capability I've been developing for
storage on my server.  It's designed where search constraints are
almost entirely defined using external filters.  It's a simple
matter of writting a filter, and you can reuse it, and whatever
logic it has repeatedly.  There are a variety of operations, and the
performance is overall pretty good.

An example of some utility filters would be the MultiFilter which
can store other filters and will either behave as an "and" (return
true if all filters return true) or an "or" (return true if any
filter returns true).

Because of typing requirements, you lose a little performance, but
overall it's a good solution, design for localized retrieval rather
than global.  Although the global lists use it as well, it scales
well due to other list optimizations.

-- Kwon Ekstrom

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