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

Marshall Spight wrote:
> Alvin Ryder wrote:
> > Bob Badour wrote:
> > > >>>
> > > >>>The RM is powerful enough to represent business data, it rocks the
> > > >>>business world but it utlimately lacks computational power and
> > > >>>conviction to go all the way in every realm.
> > > >>
> > > >>Horseshit.
> > > >
> > > > Bob, I understand how to use the RM to solve many common business
> > > > processing type problems but are you saying it /can/ be used in /every/
> > > > realm? Can you please explain how it is applicable to the games
> > > > programming and ai realms.
> > >
> > > Do games programming or ai realms need to manage data?
> >
> > Bob, all I'm saying is I'm a fan of Oracle and the such like when it
> > comes to business systems but when it comes to games and ai they just
> > ain't on the map, a clear zero. If you can convince me otherwise I'll
> > be pleased to listen but meantime I don't know what you're trying to
> > say.
>

Hi Marshall,

Thanks for your reply.

> First you were talking about "the RM" but now you've switched
> it to "Oracle and the such like." They are not the same thing.

True, that was naughty of me, I was just canvasing different angles, Bob only gave me one word to go on so I wasn't sure which direction to take it.

> Comparably different: arithmetic and Excel. Do games
> programs do arithmetic? Do they need embedded Excel? Not
> the same question.
>
Fair enough.

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

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? Spatial databases held some promise but tried and tested binary space partition trees kill them everytime.

But still, I humbly ask, if it can be explained to me I'll be happy to listen and apologize for my ignorance.

> Application
> programming environments have traditionally not done
> much with data management, preferring instead to focus
> on a limited kind of imperative programming and various
> ad hoc methods for code reuse, such as OOP. In fact,
> most application programming languages haven't even
> really learned much from the realm of programming languages.
> Not every game programmer thinks this is good: see
> Tim Sweeny's presentation on the value of advanced type
> system features for game programming.

>

>

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.

And if you want ai, you'll want more.

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

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

>

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.

> I say this not a DBA trying to push my
> field into other markes but as someone who has spent
> his life as an application programmer, and who has
> seen the light.
>
>

No worries, I appreciate your passion and obvously I haven't seen the light ;-) I've only seen enough light to let me say the RM is ok for business systems (Customer, Inventory, Sales ...) but that's it.

> Marshall

Thanks for the discussion.
Cheers ;-) Received on Sun Apr 30 2006 - 09:05:32 CEST