Customer Reviews


1 Review
5 star:
 (1)
4 star:    (0)
3 star:    (0)
2 star:    (0)
1 star:    (0)
 
 
 
 
 
Average Customer Review
Share your thoughts with other customers
Create your own review
 
 
Only search this product's reviews
Most Helpful First | Newest First

1 of 2 people found the following review helpful:
5.0 out of 5 stars The most unlikely book ever to be published, April 17, 2005
This review is from: Learning to Build and Comprehend Complex Information Structures: Prolog as a Case Study (Contemporary Studies in Cognitive Science and Technology) (Hardcover)
This is a wonderful book for many reasons, but the biggest wonder was that it was ever published! It documents obscure research about an obscure programming language--and the point of the research is to find out why it is so obscure!

If you are a big fan of prolog, but are still wondering why it didn't take off, this book will tell you. For me, the biggest take away messages are these:

1. The very uniformity of the syntax--which makes Prolog "beautiful" in a sense--is a source of obscurity, because since everything is just clauses, its hard to tell what any particular clause is doing. In, say, C, its easy to tell if something is a for-loop or not--the keyword "for" is right there. But in prolog, iteration over a range of values looks pretty much like any other programming statement. There is no syntactic differentiation to help you understand the semantics.

2. In order to understand a prolog program, you pretty much have to be a master of redaction criticism. For example, a prolog program to sum up the values of all the integers in a list of integers is typically written by taking the code for the member/2 function and editing it--adding here an accumulator, there a summation, etc. This is called "Skeletons and Techniques" by Lee Naish and other exponents. It is a very powerful way to develop prolog programs, but someone else wanting to understand _your_ prolog program must first understand how member/2 works, then they must work backwards from the changes you've made to it, first determining how you've edited member/2 and what your editorial changes mean, before they can understand your code. Its very tricky!

Talk about a book which isn't for everyone! But if you are in the business of designing languages, there's lots of interesting insights here just waiting to be gleaned.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


Most Helpful First | Newest First

This product