Re: Storing data and code in a Db with LISP-like interface

Alvin Ryder wrote:
> Marshall Spight wrote:
>
> Thanks for your reply.

No prob!

> > The RM is the pinnacle of data management.
>
> That might be so but I need it spelt out to me. How is it
> relevant to games and ai?

I am happy to provide some headlines and/or discussion, but you have to admit the limitations of the medium. (As an aside: could you post a message or two that will tell me what I need to know to implement my own 3rd person shooter. :-)

The first thing that jumps to mind is "physical independence." You have algorithms that manipulate data. There are two facets to these algorithms: correctness and performance. In the tools you are used to using, these two *independent* considerations are so woven together that you (if you are like others I've spoken to) will have trouble even considering the idea that they could be split apart. But wouldn't that be amazing if they could?

Another thing that jumps to mind is managing assets, even during the runtime. You are making extensive use of collections in games, yes? Do you write all your own collection classes? Wouldn't that time be better spent working on the game itself, or the renderer, or whatever? Don't these collections classes have to be debugged? How do you handle atomic updates? Ever have race conditions? Deadlock? (Or maybe games can get away with being single-threaded, and I'm on the wrong track.)

Wouldn't you just rather write less code? If you could code at a higher level of abstraction (for much of the time) it would mean less code and more time spent on the problem domain.

> During my post-graduate studies I worked with the RM and some of its
> extensions for spatial, temporal, object and logic databases. Why would
> the RM be extended if it already covered everything?

Ignorance, mostly. In some cases, philosophical differences. In a few rare cases, adding functionality (only logic databases would qualify for that, I would expect.)

And anyway, I wouldn't say the RM is the best tool for *everything.* Just the best tool for data management.

> Spatial databases held some promise but tried and
> tested binary space partition trees kill them everytime.

You're mixing logical and physical considerations. The idea that the RM means a row store is a common but false idea.

> > One day the application programming world will wake
> > up and realize that data management is a big part of
> > what programs do, and that there are vastly better tools
>
> I agree data management is a big part of what we do but do you agree
> algorithms are also a big part.? It is not just data but data+code.

Certainly! In fact, my expectation would be that for games, the algorithms are the more important of the two.

> > out there than coding up a first-order-only, unsafe,
> > barely-statically-checked procedure using an antique
> > type system (C) or a powerful but byzantine one (C++).
>
> Games need speed, C and C++ are fast. Fast is good.
> We grin and bare with weaknesses.

Did you read the pdf I linked to?

If speed was the only consideration, then you would necessarily be writing in the fastest high-level language ever made: Fortran. For raw calculating power on large datasets, C++ simply cannot compete.

> > Our programming languages themselves would benefit
> > from directly incorporating even the simplest of facilities
> > from the relational algebra. Libraries should begin to
> > include data management engines. Doing this in a
> > principled way would be much better than the kitchen
> > sink approach that existing libraries take.
> >
> > Bob asks, directly to the point, "Do games programming
> > or ai realms need to manage data?" Clearly they do; all
> > programs manage data to a greater or lesser degree.
> > Anything that manages data could benefit from the
> > relational model.
>
> The obvious answer is "yes we manage data" but we don't want our data
> normalized, in the form of tuples with key and non-key attributes. OOP
> yes, RM no.

Oh, I see. These are requirements, eh? So I'm sure when you put the packaging together for your next game, it will trumpet "non-normalized data" and "OOP" on the cover? :-) Or perhaps these aren't requirements, but rather just the way you are used to doing things.

And anyway, I disagree that you "don't want [your] data normalized."

Marshall Received on Sun Apr 30 2006 - 18:03:58 CEST