A prolog equivalent is pervasively used everywhere right under everyone's nose - sql. Pure prolog is almost exactly the same as relational database sql, except that sql has a much worse syntax and requires declaring column names. Column names are a necessary thing for sql's use case (use by many programmers/dba's over the years), but there is no excuse for the sql syntax (attempts were made in the past to get relational databbases to get prolog syntax in the form of datalog but to no avail).
Business rules engines used in many "enterprise" application servers are also shoddy versions of prolog (when they're backward chaining. Forward chaining is inferior to backward chaining, which implies that all these rules engines should be embedded prolog's if the implementors had bothered to study up history).
Sparql is also prolog, except that you can only have facts (predicates) with three arguments.
Disregard procedural and object oriented languages - there's plenty of other blogs/essays/textbooks/papers that tell why those are wrong. Some good exlanations are in Paul Graham's and Peter Norvig's writings (google it - why lisp, dynamic languages, on lisp, paradigms of ai).
So the question is, why is prolog better than functional languages lisp,haskell,ml,ruby etc.
Here's why, in order of increasing importance
1) The syntax is incredibly simple (like lisp), and incredibly elegant (unlike lisp and any other language).
(
)
.
:-
,
"
!
;
fail
repeat
write
read
assert
retract
those are all the researved characters/words you need (if you're working in pure prolog which I'm advocating)
repeat
write
read
assert
retract
those are all the researved characters/words you need (if you're working in pure prolog which I'm advocating)
I won't bother explaining it here for newbie's - the following is a good start
A prolog introduction for hackers
http://www.kuro5hin.org/story/2004/2/25/124713/784
2) You don't need to know recursion, lambda's, closures, folds, monads, side effects, pattern matching, map/reduce's, flatten, cyclic this and that, blah blah blah rocket science.
You don't even need to know data structures - forget linked lists,arrays,trees,graphs
In fact, forget algorithms.
If you're working in prolog the entirety of computer science is irrelevant
(for programming in domains other than computer science itself of course. If you're implementing machine learning/computer vision /database systems/operating systems you would have to know computer science - but you could more elagantly do those tasks in prolog than other languages as well).
3) Prolog programs can usually be translated to/from readable english with a simple regular expression
s/(/ is /g
s/)././g
s/:-/ implies /g
s/,/ and /g
s/;/ or /g
s/fail/try the next choice/g
s/!/abandon this line of reasoning/g
s/[capital letter X]/[unknown X]/g (I can't be bothered to figure out how to do this in regex, if it's possible at all)
You could even write your program in a spreadsheet, export as csv, and convert to prolog with equally simple as above regexp (and the reverse prolog->spreadsheet).
What this means is that most/all of your program can be written by a nonprogrammer (similar to how cobol and sql were intended, except that it has a better chance of working this time because the greater inherent simplicity of the syntax).
4) When you program in prolog, you're almost always just creating a description of the world in small "orthogonal" chunks without any concious effort to do so. In functional programming there are builtin "orthogonals", like map/filter etc, but most of the time you have to work very hard to make sure you're writing elegant concise code.
Good functional programmers keep refactoring their code sitting in their repl. Prolog programs just seem to pour out in a concise form that is the only way it can be written. If this seems miraculous - just imagine that you're actually writing sql code.
There is only one obvious way to write a sql query (forget performance concerns - you're not managing millions of rows of data as you are in an actual sql database).
In sql all you're ever writing is queries and views. In prolog all you're ever writing is queries (views are just queries in prolog).
Sql programmers don't think about code refactoring - there's only one way to do it, and it's the most concise way as well, and orthogonal to all other sql code. As do prolog programmers.
conclusion :- prolog_rules.
prolog_rules :- write("Prolog is by far the best, most productive, easiest programming language ever").
19 comments:
For the point #2, I would like to know Data Structure for working. Working with knowing the Prolog language is by far not enough.
For the point #3, the :- is an <- implication. So, s/:-/, if /g is better.
Some points listed are good while others are easy to be ignored.
if you're a practicing programmer in organization with required language such as java, or if work in high performance software, then yes, data structures and algorithms are necessary.
Otherwise, if you're generating html for a website, or creating medical diagnosis syste/legal reasoning etc., you don't need to know about data structures at all (if you use prolog). (In the java case, you could write your code in prolog, have it transform to readable java, and non one would know, working prolog programmers routinely do this).
conclusion :- prolog_rules.
transformed to english
conclusion implies prolog_rules.
works better than
conclusion if prolog_rules.
and
conclusion implication prolog_rules.
Don't need to know recursion to use Prolog??? Good luck with that!
Hi! I do not understand difference between words 'imply' and 'implication,' and I treated them as the same.
Although in concept thinking :- as "to imply" is OK, the logical meaning does not support it. For example:
a() :- b(), c().
Whether there's any solution of a() depends on if there are any solutions of b() and c(). If b() and c() do not give answers, you won't get any answer of a(). It's that b() and c() imply a() but a() implies b() and c().
Man, what the hell is going on with your post formatting? I think your cat rolled over your keyboard while you were writing this.
post script: Ruby isn't a functional programming language.
No recursion and no lists, no algorithms, computer science irrelevant? I really wonder what kind of programs you write?
If you're using lists and recursion functional programming is neater, why bother with prolog?
I like to think of prolog as the perfect code generation language (because i think it is the perfect modeling language - the best way to express your thoughts),
If you want fast code/algorithmy things - model your problem in prolog declaratively and write extra prolog code to generate files of java/c whatever to actually execute.
Or in other words, write expert systems that solve those types of problems for you.
When you do that, you don't need recursion/lists and other things.
(You're just creating an ontology, from which code is generated).
Knowing Prolog involves two things: writing code, which as you say is straightforward, and optimizing code so it completes before the sun explodes, which is a complete black art.
@John Cowan: no problem, I can sell you an insurance policy for a low up-front premium, which guarantees to compensate you in the event that, when the sun explodes, your program has not completed.
I think people are making a mistake when they use prolog for anything other than creating an ontology-like thing
-if you're using it explore a large search space it's the wrong tool (gradient descent/genetic algorithms/constraint programming are better tools)
-if you're trying to think in terms of loops/recursions operating over data structures because you have a certain fast algorithm in mind it's the wrong tool (use functional or procedural programming)
But, what i'm saying is, even the above should be expressed and reasoned over in prolog (metaprogramming) as abstract entities. In other words create (or add to your existing) 'expert system' every time you want to solve a problem. Side effects or Mercury with its static typing don't make sense in the context of that. You're not exploring search spaces and so termination doesn't come into it.
Programming = metaprogramming = organizing information = database.
The competition for prolog is all the model driven architecture/code generation/uml, ide's (like eclipse), ontology editing tools (like protege),frontends to databases,and scripting langauges, and i think prolog easily beats them.
Yes. To process large volume of data, the List must be used, and then the Recursion must be used for processing a list.
To Marshall: On "large search spaces," can you show that any recursive program has a smaller search space than a non-recursive and equivalent program?
On large search spaces it's not a matter of recursive/procedural/logical programming - it's you're search algorithm. Prolog has depth-first search which is simplitic and always worse than all the numerical/combinatorial optimization algorithms.
To process large volumes lists and recursion is also the wrong choice - you would use distributed algorithms like map/reduce (or iterative for/while loops for smaller but significant amounts of data - except in certain instances where tail call optimization is present and you're used to that way of thinking).
I think that the MapReduce is a programming paradigm. Maybe one day it becomes a mechanism like the garbage collection. Until that, a distributed Prolog program must be settled on at least two computers, isn't it?
Map/reduce is already present in all functional languages and prolog. I'm talking about in the context of large data processing (where one computer is not enough to process it). It's available as hosted versoin on amazon web services (and used inside google).
Do map/reduce, which is about that in the context of large data processing, present in all functional languages? Does what you mentioned present in the virtual/abstract machine of any functional language?
I'm sorry, I meant 'small' map/reduce is present in functional languages that i know of
what is more maintainable haskell or prolog????....plz answer quickly..
Post a Comment