During one of our artificial debates with my goto-guy, I restudied “What Goes Around Comes Around“, where while discussing the Object-Relational model we read:
Lesson 14: The major benefits of OR is two fold: putting code in the database (and thereby blurring the distinction between code and data) and user-defined access methods.
And Lisp does this since when?
Managing organized complexity 
OK, so what useful lesson can we learn from this, that is applicable to databases? That we should be using Lisp to build databases? The same blurring between code and data occurs in low-level assembly code. Is it correct to deduce that we should be building databases in assembly?
I thought you’d focus on the “code in the database” angle and go for the common argument that RDBMS have stored procedures, too :-)
Panagioti, Franz Inc. (the company behind Allegro CL) is already building databases and object persistence stores with Lisp, eg. AllegroCache.
The way I read the Lisp reference of Giorgos is that “code is data is code is data […]” is not an extremely new idea, but merely an idea that has been part of Lisp-family languages for a long time. Maybe its time is actually coming :-)
@Panagiotis Astithas:
Keramidas read my point well. It should not have been such a long time for database people to understand that code can be data and vice versa.
I do not advocate one solution that fits all; we should use the right tool for the problem at hand. I just expected that “in the old times” ideas from one field could jump faster to the next.
@Giorgos Keramidas:
One can also use Pico Lisp if one wants a GNU licensed solution (with no Common Lisp features).
Maybe my response is not very clear without the context of our artificial debate that George mentions. I definitely agree that Lisp has pioneered this, as well as many other important topics in CS. I can’t see its relevance, however, to the rapidly evolving story of DBMS. Even though Object-Relational DBMS blur the boundaries between code and data, they are nowhere near the homogeneous soup of S-expressions. And no such system has been proposed and met with substantial acceptance to this day, to the best of my knowledge. CouchDB is the closest one, since it stores JSON objects and can execute JavaScript queries, but JavaScript cannot compare with Lisp in the blurriness department.
To put it another way, I do see the similarity, but I don’t think it’s one we should focus on, if we were to speculate on the future of databases.
The context of our debate is stuff I (adamo) do not like about the noSQL crowd that remind me of stuff described in “What Goes Around”. Since he (Panagiotis) uses non-relational databases, this debate helps me understand where I might be wrong.
There is actually stuff about noSQL that I like, for which a blog post is in progress.
Looking forward to that (and also reading “What goes around comes around”)!