[om-list] Languages

[Mark Butler]

Python is a nice language, but I think we should stay with Java and C++.  We
don't really need the high level features of Python or Scheme, just a
framework to store and execute functional expressions.  That is primarily a
database issue, not a language issue.

Java and C++ are much more mature environments for building applications with
sophisticated graphical user interfaces, and I believe that is a compelling
advantage in this case.  We can easily build dynamic function evaluation in to
either one without developing a full blown language.

I want to develop a real language someday that will almost certainly be
implemented in C++ for performance reasons, so I naturally want to support C++
bindings to whatever database we use as a way to lay the ground work.  Since
Java and C++ are so similar, it would be easy for me to port mid-level
functions between the two languages where necessary.

I generally see Java as a great way to develop general purpose cross-platform
client applications and C++ as the preferred way to develop specialized,
performance critical applications.  I think our current plan to develop a
prototype general purpose client in Java is just fine, especially if we
maintain the ability to write independent analysis applications in C++.  

The ability to use different languages is the main reason why we need a
general purpose database server in the first place.  FramerD has real
potential as a technology, largely because it is the most flexible one readily
available to us. (A good commercial OO database like Versant would be an
alternative).

Even if we don't end up seriously using it, I think FramerD is a very useful
tool for getting out of the relational database mentality, which is necessary
because we are working on a meta-model a full level more abstract than what
real world relational databases (and database designers) are inclined to do.

To that end, I think it would be a very productive discussion to look at how
we would implement our current data model using a LISP style representation
such as that supported by FramerD.

 - Mark