First of all I will only advocate the use of pure prolog - that means
no recursion, lists, forall's, and any other features. Extra features
that were added destroy the whole point of the elegance of prolog.
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)
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").
黃耀賢 said...
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.
February 6, 2010 1:59 PM
Marshall Pound said...
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.
February 6, 2010 3:05 PM
Anonymous said...
Don't need to know recursion to use Prolog??? Good luck with that!
February 7, 2010 12:33 AM
黃耀賢 said...
This post has been removed by the author.
February 7, 2010 12:45 AM
黃耀賢 said...
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().
February 7, 2010 12:46 AM
Anonymous said...
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.
February 7, 2010 2:07 AM
Anonymous said...
No recursion and no lists, no algorithms, computer science irrelevant?
I really wonder what kind of programs you write?
ebruary 7, 2010 3:12 AM
Marshall Pound said...
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).
February 7, 2010 11:59 AM
John Cowan said...
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.
February 7, 2010 3:16 PM
tontobius said...
@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.
February 7, 2010 5:48 PM
Marshall Pound said...
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.
February 7, 2010 6:49 PM
黃耀賢 said...
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?
February 8, 2010 10:55 AM
Marshall Pound said...
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).
Obviously what you mentioned, an easy programming tool, is a SQL
replacement.
I stopped reading here. This is pure nonsense (I could use stronger
words, but lasioes and kids are reading this group). It seems that you
know about Prolog as I know about life on Mars.
A.L.
Perhaps if you further explain why have written off completely a
fellow prolog afficiondo we could all benefit, logic programming needs
all the advocacy it can get I found the article inspiring personally,
and I agree on his point about 'not needing to know algorithms and
data structures', after all thet is the whole point of prolog,
programming in logic, and why many of us are here on this forum.
Could you translate?...
A.L.