Hey guys, I've been meaning to start a thread on Prolog for a little while now. Before I get into any actual code, let me provide you with my motivation for learning/using Prolog. First, I am a big fan of prototyping. I don't want to really get into why that is the case, but I've always felt that projects which incorporate a DBMS make prototyping difficult. Part of the reason for this is the tendency of database programmers to run off and start creating a schema and queries the very moment they seem to think they understand the project. However, I also feel that DBMS systems just aren't very prototype friendly (at least I haven't seen anyone use one in a prototyping manner nor have I uncovered anything that I consider to be good for prototyping). Sure, I know there are all kinds of gui programs for creating tables and fields and queries and what not. Personally, I haven't seen or used one that I didn't think mostly sucked, but I don't want to get into a whiteboard & SQL vs gui tool flamefest either. They're also not the real the problem either. The problem is the actual SQL specification / DMBS forces you to define every stupid effin detail in advance (which you never know up front hence the need for a prototype): This table has 8 fields named... and this field is a number(4), this is a string(20) or wait, make that a char(20) instead; Ah crap, the project manager forgot to tell us something and now we're going to have to repopulate the entire database -- damn". You just can't create a database quickly... there is too much unnecessary overhead involved.
While a DBMS fights prototyping every step of the way, Prolog doesn't fight with you. You don't have to tell Prolog datatype info... It will figure it out. All of the data is in a text file. If you need to rename a "field", which is called a fact in prolog, simply rename it in your text editor and reconsult the file. It's a sub-10s change. Ditto if you forgot a field in a table, screwed up a relation, etc. It can rightfully be called a DBPS -- Database Prototyping System. Granted, you don't get any of the ACID properties of a DBMS, but you don't need them during prototyping either.
Second. Prior to using Prolog, I had heard that Prolog programs or code often resembles software engineering specification documents more so than 'code'. I hadn't really noticed this when working with Prolog in the past, but the work I had done was in AI classes where the focus is on AI and not programming. Now that I have done some 'pragmatic programming' in Prolog, I can say there are instances where Prolog programs or queries really do resemble the specification (esp when dealing with recursion). In fact, there is quite a bit of research involving using Prolog for Software Engineering purposes. Hey, some software engineering we can all get behind!
Finally, my research interests include automated theorem provers, so logic programming is obviously an important component of such a system. Hopefully, my motivation for learning logic programming and Prolog has given you something to think about. I'll get into some programming in a bit.