[om-list] Re: Language Power

[Luke Call]

In reply to what language(s) to use and the pros/cons with respect to 
our requirements, I appreciate what Mark and Tom are thinking. I have a 
few quick thoughts, but the short version is that we can embed Scheme, 
Lisp, Python, or a variety of other languages both in our database and 
in Java code at runtime quite effectively, and I'm hoping this will meet 
our requirements enough to get as far as we need to go in the next 5-7 
years, after which we'll have so much experience that we or someone will 
know more clearly what the next steps should be for a system like this. 
(Here's a link on other languages in Java:
      http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
).

One nice thing about java is that it has tools to access so many other 
things.

We have discussed this before, though from slightly different angles 
perhaps. I don't yet (unfortunately) fully understand how this works 
with lisp--how lisp stores the data for scientific/engineering problems 
that we can't with our current model. Not saying it isn't so, but I'm 
not there personally yet, which is why we're a team anyway....  I do get 
that we'd need lisp/scheme or something as an inner language to express 
things within the model that rows/columns can't so well (as discussed 
before), like formulas, algorithms, and actions performed by entities 
inthe model, at the least. I used Scheme in college some but would have 
to bone up, and like others, I haven't used macros or those other 
advanced features....yet.

Also in java I'm fairly sure that at runtime you could create a source 
file, compile it, store it, and load and execute it, in a pinch. Not to 
say you'd want to though, when lisps are suited for such things, and 
this would be so very awkward in various ways.

Given what Mark understands about all this, I'm again asking the 
question: will this combination get us where we need to go, at least for 
the next 5-7 years? This is an honest question. So far it seems to me 
that it will, and given that I can't code something that I don't grasp, 
that's where I have to work for now, I suppose. But I try to keep an 
open mind, albeit a small one.  :)


>>  If that makes it run to slowly, we'll have the option to increase the
>> speed and the storage.  I think OM should be about options: the user has the
>> option to use a powerful feature if he doesn't mind additional costs
>> elsewhere.
> 
>  I agree in principle, but in order to accomodate that desire in version one,
> the first thing we would have to do is give up on using any existing database
> technology and adopt a language like LISP.
> 
> The big difference is that our current proposed model is quite capable of
> modeling the majority of what people actually know - i.e. what they can
> actually fit inside their heads and what they can actually use to reason
> with.  ITs major strength is scalabity - we can easily store information about
> millions of objects.
> 
> The type of information you are talking about is very useful for a wide class
> of scientific and engineering problems, but is so dense that you are lucky to
> store information about a few thousand objects.
> 
> The impedance mismatch between these two sets of requirements means that using
> current technology you need to split into two different versions that are
> optimized appropriately:
> 
> 1. DBMS based, disk oriented, very large numbers of objects, simple attributes
> 2. File based, memory oriented, smaller number of objects, 
>    very complex attributes.
> 
> The only way to support both well is to develop a superior database
> technology, which is roughly the same complexity as developing a new operating
> system.

Maybe this is what we'll do, as this evolves. That would be great if it 
can work out that way, but I don't know. Thoughts, opinions??

Thanks,
Luke