Re: approaches for embedding a data language in a general purpose language

From: Marshall <marshall.spight_at_gmail.com>
Date: 10 Oct 2006 23:09:45 -0700
Message-ID: <1160546985.449754.247300_at_i42g2000cwa.googlegroups.com>


On Oct 10, 6:18 pm, "David Cressey" <dcres..._at_verizon.net> wrote:

>

> There is no particular reason why a language couldn't embrace both the
> functions and operations needed for relational data manipulation and also
> the functions and operations needed for general purpose programming tasks.
> There is no particular reason why such a language shouldn't be developed.

Sure; I'm completely signed up to this idea. In fact you could say I'm actively
pursuing it, in what is colloquially known as my "copious spare time."

> How quickly such a language would be adopted by either DBAs or programmers
> remains to be seen.

Language popularity is not well understood. Very tricky question.

> I'm not sure about legacy systems. Can you explain that in a little more
> detail?

Sure.

Suppose you create a new language that is both a general purpose programming
language (Turing complete, able to code any computable function, various
modern language features) and also a first-rate data language (joins, aggregates,
imperative statements, etc.) Let's just assume you do a good job and many
people agree that it's awesome, and they want to use it instead of SQL, even
when connecting to their existing SQL databases. (With appropriate connectors,
it would be possible.)

But few people will be in a position to move to using the new language in
a homogeneous way. Most will have a substantial investement in existing codebases. They have lots of Java and C++, probably. (Lots of SQL too but let's ignore that for now.) Maybe (in an enterprise setting) they commission a new database using the new DBMS that supports the new language natively. They'll still have a lot of existing databases managed with SQL DBMSs. An existing application, written in C++ or Java might grow to need to access the new database, and maybe they want to use the new language to do it. You have to have some way to embed the new language in C++ and Java, the way you can embed SQL in C++ and Java today.

Something like that anyway. There will likely be many scenarios that require various forms of interoperability.

Marshall Received on Wed Oct 11 2006 - 08:09:45 CEST

Original text of this message