Σχόλια στο Lesson 14: http://blog.postmaster.gr/2009/10/26/lesson-14/ Managing organized complexity Mon, 06 Feb 2012 23:51:36 +0000 hourly 1 http://wordpress.com/ Από: Panagiotis Astithas http://blog.postmaster.gr/2009/10/26/lesson-14/#comment-43507 Mon, 26 Oct 2009 15:33:35 +0000 http://blog.postmaster.gr/?p=2777#comment-43507 Looking forward to that (and also reading “What goes around comes around”)!

]]> Από: adamo http://blog.postmaster.gr/2009/10/26/lesson-14/#comment-43506 Mon, 26 Oct 2009 14:17:53 +0000 http://blog.postmaster.gr/?p=2777#comment-43506 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.

]]> Από: Panagiotis Astithas http://blog.postmaster.gr/2009/10/26/lesson-14/#comment-43505 Mon, 26 Oct 2009 14:06:02 +0000 http://blog.postmaster.gr/?p=2777#comment-43505 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.

]]> Από: adamo http://blog.postmaster.gr/2009/10/26/lesson-14/#comment-43504 Mon, 26 Oct 2009 14:05:27 +0000 http://blog.postmaster.gr/?p=2777#comment-43504 @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).

]]> Από: Giorgos Keramidas http://blog.postmaster.gr/2009/10/26/lesson-14/#comment-43503 Mon, 26 Oct 2009 12:48:33 +0000 http://blog.postmaster.gr/?p=2777#comment-43503 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 http://blog.postmaster.gr/2009/10/26/lesson-14/#comment-43500 Mon, 26 Oct 2009 09:43:05 +0000 http://blog.postmaster.gr/?p=2777#comment-43500 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 :-)

]]>