I did learn prolog during my engineer degree but we never went further than the "school" exercises of finding if Mary is a member of the family of Bob or not.
I then later played, while still being a student (i.e still playing with things for intellectual fun rather than actual real life/business problem solving) a bit with Flora2 http://flora.sourceforge.net/ that seams to me like a hackier but stronger variant of Prolog (the object-like syntax and the possibility to pass rule has parameter to other rule).
All of that to say I really hope I'm missing something with Prolog that can elevate my thinking.
At work, we have a very large set of data representing individual "runs" that has to be "scored" (given various different numbers) in an ever-growing list of complicated ways. Originally these scorers were written in Python. This proved to be very difficult to maintain, and we recently moved to writing these in a Prolog-like language (not Prolog, but close enough for this discussion). At the end of the day it feels kind of like a much more powerful SQL (which makes sense, as SQL is a "relational" programming language and quite similar in concept). The facilities of logic programming perfectly fits this use case.
Similarly, you might take a look at anything people use "miniKanren" (an embeddable logic DSL) for. The fundamental thing to realize about Prolog, imho, is that while it's Turing-complete and has GUI facilities I wouldn't really call it a general-purpose programming language. It really works best as something like a DSL when you have tasks that require lots of logic and searching.
edit: Actually, writing this, I have a list for you. Do you need to perform a search and compute a result over a big data set, sort of like (in theory) you would with SQL on a relational DB? Then that's where logic programming languages shine.
If my link epic fails its "Representing Game Dialogue as Expressions in First-Order Logic" by Kaylen FJ Wheeler
Something like using clojure core.logic which is a minikanen which is prolog to implement video game dialogue programatically. Its a one line summary of 100 pages so take with grain of salt.
I have no connection with this topic other than skimming the paper when I went thru a phase after reading the most recent 7 languages in 7 weeks book and googling for minikanren applications and generally fooling around with the topic. There may or may not be better example, but it is at least "an" example.
NLP is old territory for AI and lisp and the like. Whats interesting about this specific part of NLP is limiting the territory and "guiding" it to fit a gaming requirement and integrating the conversation with game plot, more or less.
As another example, I thought for a bit about some kind of prolog reasoning engine to help with some ETL stuff I do and got pretty much nowhere, although it also is a limited area of NLP type stuff. There probably is some way to apply it... somehow. There should be a way to semi-intelligently read engineering data formatted in vague and confusing ways then reason about how to correctly import it.
Shawn Pearce, the author of Gerrit, explains why he thinks Prolog is well suited for this:
It's mostly a rather simple agent but I'm currently working on a DSL to codify strategies more easily. I'm fully aware a rules based agent will never be strong but I'm mostly interested in figuring out how well experts can codify their strategies and if you can make them comparable (also looking into inductive reasoning and datamining strategy rules from sufficient hand samples of winning online players)
Mostly a toy project these days :)
[Edit: I'm actually going to rewrite it because it used Sicstus and I want to use an open implementation so I'll switch to SWI + while I'm at it I'll drop the Java stuff and go full JS/HTML. Pengines looks pretty good: http://www.swi-prolog.org/pldoc/package/pengines.html]
> Two new specific software languages known as "PROL-2" (used by the on-board computers) and "DIPOL" (used by ground computers using vehicle testing) [...] were developed for Buran
So I guess the what the CIA report refers to as Prolog is PROL-2. But is this really a Prolog variant? That seems like an unlikely choice of language for a real-time system.
Later, both of these languages developed into DRAKON , and looking at the Wikipedia page that language doesn't appear very Prolog-like, at least not superficially.
On the other hand, here is a reddit comment that claims that is was indeed a Prolog variant, but it doesn't cite the source.
My old German university's web server was written in prolog, so it's not completeley inconceivable for a spacecraft, but I'd like to see more evidence.
We basically took about 120k daily events and turned that into about 60 actionable events that were meaningful to the NOC... All in about 2,000 LoC.
The theorem prover logic was in Prolog: it was totally the right tool for the job, and was small, effective, usable and (relatively) easy to understand.
The MacOS user interface was also in Prolog: it was totally not the right tool for the job, and to this day I am still astonished that it could even be done, let alone produce a usable UI.
Michael Hendricks' talk at last year's Strange Loop on "Production Prolog" gives an excellent high-level survey of the uses, advantages, and drawbacks of Prolog: https://www.youtube.com/watch?v=G_eYTctGZw8
BTW, I have played a tiny bit with Flora2 myself. It seemed really neat. If you're interested in the intersection of OO and Prolog, you may also want to look at Logtalk. FWIW, if I understand your meaning correctly, it is very easy to "pass rules as parameters to other rules" in vanilla Prolog. It facilitates all sorts of higher-order approaches and is very good for meta-programming.
Today constraint solving is still confined to a lot of niche applications like physics engines or CAD systems, but I keep hoping for the day that someone will build a more integrated system which makes it easier for anyone to grab constraints and plug them in where it makes sense.
I once had to write a menu system in Turbo Prolog. Not fun. Totally the wrong tool for the job. Prolog isn't that useful when you have to cause an action, as opposed to computing a result.
: e.g., SWI Prolog's http://www.swi-prolog.org/pldoc/man?section=clpfd, or http://www.swi-prolog.org/pldoc/man?section=clpqr
I think Prolog rules can replace a lot of spaghetti code: stuff like "Usually do this, but then other times do this, unless this other thing is true. If there's a parse error, then do xyz and keep going." In ordinary procedural code, the exception cases can dominate the body of a function and may need to be deeply nested, but in Prolog, it's possible to cordon them off or express them at the top level.
I suspect it might be most useful as a DSL you can embed inside of other languages, though I haven't seen a good implementation of that. (The clojure core.logic library mentioned elsewhere looks really promising.)
I think it may also be useful for domain experts to specify simple rules that capture an aspect of their expertise. If you restrict the domain down enough, and work to figure out what predicates are needed, prolog rules can become easy enough to read that you don't need to know much programming to use them. But the devil seems to be in the details of connecting the core logic into a bigger system that actually does something.
For example, the answer for hooking prolog up to a SQL database is "Look at the ODBC library!", which is not a very satisfactory answer. I think you could build a really beautiful ORM system in Prolog, but nobody's done it yet. (Maybe ORM isn't the right phrase, but a clean way of relating prolog queries to database queries and vice versa.)
The syntax is wonderfully simple, but also has almost no sugar for common idioms. The predicate notation makes it somewhat harder to batch up a bunch of attributes into one conceptual "thing" than in other languages. That means you need to keep positional arguments in your head a lot more. I think aping the class constructor and attribute notation of other languages would be helpful like `my_foo(foo, bar:attr, baz:attr) :- [...].` Then you could reference that either as a constructor (`my_foo(a,b,c)` would state that `a.bar=b` and `a.baz=c`) or to generate goals, like `my_foo(foo), other_predicate(foo.bar)`. Prolog is so old that choices like "make '.' the end of a statement" made sense at the time, but haven't stood the test of history.
(Disclaimer: Many of my criticisms may have perfectly valid solutions in prolog. I'm still learning it.)
This is almost exactly like the descriptions I get from my team leader for getting results out of a database. He doesn't think in sets for SQL.
I love Prolog syntax. I do think there is room for improvement, but the language is also extremely flexible, and it is very easy to roll your own syntax. Funny enough, so far my many experiments with alternative syntax have mainly had the effect of convincing me of the elegance and power of standard Prolog syntax.
While there is no particular reason the '.' should be used to terminate statements (except the resonance with many natural languages in this regard), I think some sort of terminator is necessary to keep the syntax as flexible as possible. Like Lisp, Prolog syntax is isomorphic to its AST. Currently my main gripe with Prolog syntax is that it represents conjunction and delimitation of predicate arguments and list items with the same operator, `(,)/2`. However, that can be fixed in two lines:
:- op(1000, xfy, user:(&)).
A & B :- A, B.
Regarding, "batching up a bunch of attributes into one conceptual 'thing'": SWI-Prolog has implemented a special data structure it calls "dicts"[dicts] for this purpose, but I am not very fond of it (and there's a fair amount of concern over the way this implementation breaks compatibility with ISO standards). More traditional solutions are to use lists of "pairs"[pairs], option lists[option], or, for larger data structures and when performance and lookup time is an issue, association lists[assoc] or records[records]. Using the first of these techniques looks like this:
my_foo(a, [bar-Bar, baz-Baz]) :-
Bar = something,
Baz = something_else.
get_attr(Pairs, Key-Value) :-
set_attr(Pairs, Key-Value, NewPairs) :-
( select(Key-_, Pairs, Key-Value, NewPairs), !
; NewPairs = [Key-Value|Pairs]
?- my_foo(a, As), get_attr(As, baz-X), writeln(X), set_attr(As, boz-another_thing, Bs), writeln(Bs).
As = [bar-something, baz-something_else],
X = something_else,
Bs = [boz-another_thing, bar-something, baz-something_else].
Thanks for the links! These look extremely helpful!
As a result, the order you write your constraints ("trees") in in Prolog is /very/ important. Things may not terminate or may blow up the stack or take far, far too long or produce the wrong I/O if the order isn't just right.
So standard Prolog is not a nice language.
But the idea of specifying constraints and let the computer find solutions is really nice. If only we didn't have those side effects weaved into the constraint solving process. And if we could specify the constraints separately from heuristics on how to solve them (i.e. the order in which to try things). Or if it could handle something more interesting than just "trees with wildcards".
mini-Kanren seems to be such a better constraint solving language -- I haven't tried it yet, since I am not done with my Prolog studies but I'm very much looking forward to it.
Some Prologs have extensions that ameliorate or completely fix some of the problems with Prologs. GNU Prolog, for example, has an extension to handle other kinds of finite domains (such as integers) than just trees:
I think the same guy who wrote that code also has a nice paper on how to extend it (efficiently!) to floating-point variables.
I have to say I was not only amazed by the exact solutions provided, but that it was found in 12 milliseconds - which includes program load and I/O time.
I also use full Prolog to implement type systems.
Prolog extended with a constraint solver is another thing one may want to employ for an elaborate program analysis, see how https://github.com/eholk/harlan is using cKanren for its region inference.
So, in my book, Prolog per se may have very limited use outside of teaching, but an embedded Prolog or a dumbed down Datalog can be an extremely powerful querying DSL which can make LINQ look dumb and clumsy.
I read that in 2014, 1/3 of all flight bookings in the word went through (Sicstus) Prolog.
It has its uses, and I like working in it :)
Most (all?) of the build systems out there today (make, CMake, rake, etc.) are declarative but they lack Prolog's inference capabilities. This gives a specific advantage -- it allows you to reduce fragility of your build system by making it dead simple to tell when you've combined incompatible configuration options (e.g., compiler flags) which you might otherwise discover halfway through a long build.
For a quick overview, check out the paper prom: A flexible, Prolog-based make tool.
Two things that you'd get, that to the best of my (limited) knowledge aren't possible in make, is having cut, and the notion of both "and" and "or" - not only can you declare multiple dependencies and rules, but also "alternative" rules in case one does not succeed (e.g., in case you shell-out to a non-existent binary, try a different one).
* One database containing facts about which GCC flags are incompatible with one another (i.e., cases where you can't specify both --foo and --bar). This would ideally be provided as part of the build system itself, since it's not going to change for every program built with the system.
* A small database (if one is even needed) you'd specify in your build scripts where you can enumerate specific flags or compiler features you know shouldn't be used with your program. This would augment the database provided by the build system for your specific compiler.
Note, I'm not suggesting that using Prolog to define a build system would make it impossible to specify bad or incompatible compiler flags. I am suggesting that deriving the set of flags to use for a build based on known facts about the compiler being used and your program makes it much less likely that a change you make to a build script causes the build to break in subtle ways once you've started compiling (or worse, at run-time). With Prolog, it'd be easier to detect such issues up-front so you can fix them before you start compiling or deploying.
I realize that prolog is a language, but it's much harder to learn things when they are purely abstract. A good implementation and a good library go a long way.
I don't have a problem with non-mainstream languages. I like erlang.
I tried learning haskell, too. I didn't get hung up on monads; I ran into a wall when I found out there was no good way to use haskell as an embedded language or call a haskell library from something else without pulling in a big runtime (which interferes with non-trivial host applications). Correct me if I'm wrong.
It also has a bi-directional interface to Java, but Sicstus is unfortunately neither free nor cheap
(see the answers to questions #3 and #6)
And encoding it in XML does not help.
Public database examples: http://flybase.org/ , http://dbpedia.org/ , http://disease-ontology.org/
Ranking 845 doesn't seem to me to cut it.
I have written a few semantic web books and I guess I am still a fanboy, but I also agree with you that "classic" semantic web apps using the W3 standards have had only partial acceptance into mainstream use while similar graph based systems like Knowledge Graph affect how many people use the web (at least for search, Google Now, etc.).
The goal of RDF and the semantic web was to make things easy, but after using it, it makes things much more complicated.
Finally, on the topic of encoding. The old defacto standard of encoding RDF was XML. More recently, Turtle has become more popular, and that really helps the human readability of RDF by an order of magnitude.
I don't think I'm alone in this. None of Semantic Web stuff ever really made sense to me.
Freebase will be closed on March 31, 2015 (largest open collaborative knowledge base): http://www.freebase.com , http://en.wikipedia.org/wiki/Freebase
Freebase has 2,751,614,700 facts, Wikidata has 13,788,746 facts.
Freebase was acquired by Google and their internal Google Knowledge Graph is based on it. Wikidata may import some data of Freebase, but due its stricter guidelines (notability...) many facts of minor will be lost/never migrated. A Freebase dump won't age well, in a lot of cases up-to-date facts from the real world are required. (ex "Who is the current president of the USA?" "Bill Clinton")
Maybe some community project like Archive.org, Apache Foundation, Wikipedia.org, Mozilla can rescue the Freebase community project before it is too late?
From my point of view (I worked a few years with the language while in academia), there are no real job offers where Prolog makes a difference.
So maybe erlang people prefer a Prolog background but that's it (w.r.t. a job market perspective)
Given that Prolog isn't super-widely used (compared to say, C++), there are going to be a limited number of developers with Prolog expertise. That means companies who use it in their tech stack are generally going to have to hire developers who fit the other qualifications for the role then put them through some internal Prolog training. The listings for such positions probably won't have Prolog as a "required" skill but a "desired" skill.
One other point -- just because there aren't any/many jobs where Prolog is required doesn't mean there aren't many cases where Prolog could be useful. Prolog hasn't been widely taught for a couple of decades, so a significant proportion of developers today won't recognize a problem that Prolog would be a good solution for as a problem that Prolog would be a good solution for.
There's a Strange Loop 2014 talk on YouTube, "Production Prolog", that might give ideas about jobs that use (or could use) Prolog: https://www.youtube.com/watch?v=G_eYTctGZw8
Good. It is such a powerful language. I ended up writing a console game as a side project and was simply thrilled with ability of the program that can "take" decisions and play the game along.
This was in a mechanical engineering group, so it took some time for some people to get used to such e different language.
People might not be aware that the JVM (Java Virtual Machine) specification includes a class verifier written in Prolog, see http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf
Clementine -- a data mining application purchased by SPSS
SPARK toolset -- a rigorously defined Ada subset used for developing software correct by construction. This approach is used in areas like
aviation, transportation, medicine, energy, etc. where failure is not an option.
ECLIPSE-CLP -- an open source constraint logic programming library used to solve various resource allocation problems. Think of it as a poor man's
Operation Research expert.
Experian, the credit rating company, bought out Colmerauer's Prologia company: http://www.experianplc.com/news/company-news/2005/25-10-2005...
ContractExpress/DealBuilder from Business Integrity Ltd
InFlow from OrgNet
GridMind tool - a for modelling and simulation new technologies implementation into energy grids (smart grids, smart metering etc.). They have to generate detailed complex models satisfying lot of rules which to make models realistic. Prolog together with CLP is excellent tool for that. Fast development, small code, elegant solutions.
David Warren (Leading Professor at Stony Brook University): "We at XSB, Inc. use Prolog and Java. We use Prolog for knowledge extraction and standardization and for ontology representation. We have (to me, somewhat surprisingly) found that our Prolog code is more stable and we spend less on maintaining it than we do our Java code. It may be programmer skills, but I think it is also due to the much more succinct expression of similar functionality."
The Nokia N900 phone used prolog to do ui state management .... prolog in a smartphone!
London-based startup Texrazor performs text analysis via API and the engine behind it is coded in Prolog http://www.textrazor.com/technology
Prolog does social and organizational network analysis for clients around the world. http://orgnet.com/inflow3.html
Orgnet, LLC also uses LPA Prolog to do data analysis, especially for hidden relationships and patterns in business data... for examples, see: http://thenetworkthinkers.com
etc., see the discussion on LinkedIn
Erlang's syntax was also influenced by prolog.
EDIT: apparently i recalled correctly: http://www.erlang.org/faq/academic.html