[om-list] Re: Language Power

[Tom and other Packers]

Luke

    I have the tendency of calling C++ "blub", if you know what I mean.

    I'll work on not calling C++ blub if you do the same for Java.

    :-)

tomp

----- Original Message -----
From: "Luke Call" <lacall at onemodel.org>
To: "One Model List" <om-list at onemodel.org>
Sent: Monday, May 07, 2001 7:05 AM
Subject: Re: [om-list] Re: Language Power


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


_______________________________________________
om-list mailing list
om-list at onemodel.org
http://www.pairlist.net/mailman/listinfo/om-list