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

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Jon Lambert wrote:

> SQL is a 4th generation programming language and is
> algorithmically non-predictive by design.

4th generation... blah... All SQL provided was syntactical sugar and
a lack of expressiveness... It is better described as a query
language IMO, designed to be so close to English that your CEO can
use it.

Shouldn't 4th generation actually have domain knowledge?

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

Can you easily deal with hierarchical/recursive structures in SQL?
I thought SQL was pretty much tied to fixed tables.

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

I don't know what HLL is, but you basically missed the point.  How
fast you can generate complex queries was not the issue we
discussed!  Hell, if that is the criteria then grep will rule the
day!

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

So what? I haven't claimed that you can't do a MUD using a
relational database. (and I don't think I've explicitly called for
undefined user actions, I am in favour of a small and powerful set
of 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 don't think it has to, (the physical world does not), but I think
it is a good idea to have an optimizing search/unification engine
"down there". A virtual world should be more powerful than the
physical, not less. Still, some areas such as spatial subsystems
require informed optimization.

The fact that I am in favour of an search/unification engine does
not mean that I think it can be efficient. I'd settle for an engine
that gets the results on time with sufficient precision. (yes, I
don't mind fuzziness and non-determinism) So rather than claiming
that it won't be slow, I'd rather go for an engine that provide
neither optimal nor consistent solutions.

As much as I love arguing with you, Jon, I'd appreciate if we could
separate the different issues. That makes for more reflection, and
less noise... :)

--
Ola

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