
Ask HN: Why isn't Prolog more popular? - miguelrochefort
Also, what would it take for Prolog to become a great general-purpose language?
======
PeterisP
For me, the big problem with Prolog (and the whole concept of declarative
languages) is that the intended benefit requires an unreasonably (or
impossibly?) smart compiler.

The concept works when I can declare what I want to be done, and the system
does it - and when that happens, Prolog is great, the language is great for
declaring what I want to be done.

However, often it happens that the system does it in a way that's somehow
horribly inefficient and makes it totally unusable. And _then_ I have to
redeclare my requirements in a slightly different way to nudge the system into
doing it differently - and this is much harder, then I have to worry about
much more moving parts than just my code.

Also, the language is not really well suited for that; if I have to specify
how exactly in which order the calculations need to be made, then imperative
languages are a much better tool. I'm throwing away all the advantages of
Prolog if I have to do this all the time - and in practice I do.

Haskell has a bit of similar problems (though generally not with unexpected
speed complexity but unexpected memory complexity through laziness and
thunks), but Prolog is much worse in that regard.

~~~
agentultra
> For me, the big problem with Prolog (and the whole concept of declarative
> languages) is that the intended benefit requires an unreasonably (or
> impossibly?) smart compiler.

I'd say... sufficiently smart. We've been writing SQL for decades without such
complaints and it works rather well in practice. Sometimes you have to
introspect your queries and interact with the underlying interpreter to
understand the performance constraints but it is much better than the
alternative! Imagine having to write every query as a procedure... what a
headache and the duplication!

Although learning to write well-performing queries does, I think, take some
understanding of the underlying theory driving relational databases and SQL...
which can be true for Prolog as well.

I'm not really sure why Prolog isn't more popular. Any time I've written
declarative DSLs for a solver engine it always feels like I'm re-inventing an
under-specified sub-set of Prolog.

After all the calculation of computer programs is the syntactic manipulation
of predicates, is it not? Maybe if we all started with first-order logic and
predicate calculus a language like Prolog would appear to be more practical. I
think for a majority of programmers however it can seem a bit alien as we're
trained to think in terms of procedures and steps rather than invariants and
predicates.

~~~
barrkel
_We 've been writing SQL for decades without such complaints and it works
rather well in practice._

Speak for yourself. My experience of SQL is that it requires careful tuning
whenever the numbers involved grow beyond the trivial. Query plans need
inspecting, and often indexes aren't used appropriately. Queries are written
and rewritten several different ways to encourage the database to choose one
plan or another.

If your use of a database is limited to key-value lookups and object graph
navigation with an ORM, with <100 values on any given edge, you'll have a fine
time, I'm sure. Not everybody uses databases that could trivially be replaced
with an object graph.

For more complex operations, I'd like to be able to write in the form of a
plan with a graph of data flow directly. Scan this table, filter against this
index, sort these two data sources and do an merge anti-join, etc. Today, I
need to rewrite the query while knowing the planner well enough to foresee how
it's going to implement my query, gradually homing in on my target through a
series of indirect inspections.

~~~
agentultra
> Speak for yourself.

Fair enough.

I use PostgreSQL quite heavily at present and do not use ORMs. I'd guess,
probably optimistically, that 80% of the non-trivial queries I write are
easily optimized by the query planner and require no further thought from me.
In my experience these aren't the majority of the queries I write. The final
20% of these queries are the hard ones that, as you say, require some work and
re-writing to get the query planner to choose an appropriate plan.

At least I find the tooling in PostgreSQL to be more than ample to assist in
optimization tasks.

The spirit of my example of SQL is that we already use declarative programming
languages in mainstream systems. Even with recursive queries and common table
expressions I think, and I may be wrong, that Prolog is probably more general-
purpose and expressive than SQL. And yet it's not nearly as popular for some
reason.

~~~
PeterisP
Well, but SQL is actually a quite good illustration of the reasons why Prolog
isn't popular.

I mean, you technically _can_ write all of application functionality in many
dialects of SQL, but it's generally considered a bad idea to do so for obvious
reasons - SQL is good for some tasks, but for everything else other languages
are preferred.

In a similar manner, even in tasks ideally suited for Prolog's strengths (e.g.
reasoning systems) _that_ part of the task will be relatively small - in any
practical system, the "boring" code of integrating everything with everything
else, handling a graphical UI, mangling data from one format to another,
wrapping it in a REST web API and god knows what else will be at least 3-10
times larger than the core part of that task. I recall an old project where we
had the core algorithms in Prolog, but the surrounding app in Java - the fact
that the Java code was much more than 20 times bigger wasn't a verbosity
issue, it actually did 10 times more stuff; although it was quite boilerplate,
it all was needed and it was clearly simpler/faster/cheaper to make it in Java
back then rather than do everything in Prolog. It's not sufficient for a
language to make the hard (or domain specific) things possible, it also needs
to make _all_ the easy things easy, and Prolog really does not.

So the language either needs to be truly general purpose (and "more general-
purpose than SQL" isn't sufficient) or easily integrated with other languages.
There are successful examples - for example, tensorflow->python, where again
the actual ML part for anything more than proof-of-concept is much, much
smaller than the surrounding general purpose python code; or SQL, which is
well integrated into other languages.

In another post you mention "I've written declarative DSLs for a solver
engine" \- why it wasn't trivial (compared to writing a new DSL) to include
some Prolog code _as the DSL_ inside the app as easily as people include SQL
in their apps as the DSL for managing data? There's your answer for why it's
not nearly as popular.

------
mabbo
My opinion: Humans are good at thinking sequentially, imperatively. Other
language paradigms are harder.

That isn't to say that Functional languages (Lisp, Haskell, Scala, etc) aren't
as good; frankly, I like them better. There's just a mental gap that has to be
crossed and for most developers I've met, that can be challenging. Why do
things in a challenging way when I've got Java right here and it works just
fine? (straw man, not my own view)

Prolog (logic programming) is a bigger gap, imho. It takes more effort for me
to really understand Prolog code. Can do some beautiful things with it, but
it's easier to have a few good developers be good at it and put their hard
work behind a library/API than it is to have every other developer try to get
over that gap.

~~~
SeanLuke
I think you're right.

The promise of Prolog was that you'd be able to just define the task
requirements, then write the requirements in Prolog and magic would happen.
But even the most experienced Prolog coders I know don't really think in
Prolog. When faced with a coding task, they inevitably first (mentally) figure
out the problem in an imperative form, perhaps with some recursion, and then
they they ask themselves "okay, how do I convert that to logic and pattern-
matching?"

If you're going to go through that process, then Prolog provides no value:
it's just an extra step, and you might as well code in C (okay, Lisp).

I fear that Haskell will turn out the same way. After all monads are just
monoids in the category of endofunctors, right?

~~~
nv-vn
This is really dependent on the programmers background and what they're
writing. Some code is super easy to write in Prolog and much harder in any
other languages. Take type inference algorithms for example. Rather than
describing how to solve it, you just translate the typing rules directly to
Prolog clauses. Thinking about imperative problems is hard in Prolog and will
make you think backwards. Thinking about logic problems in C is the same way.

~~~
zmonx
I second this. When writing Prolog programs, the more you think procedurally,
the more specific your programs will become in the sense that you can then
typically only use them in specific _directions_.

To make your Prolog code as general as you can, I recommend to also _think_ in
terms of relations. This definitely takes effort, which pays off in the
increased generality.

------
srpablo
I have a few ideas, but the main one is that: independent of the
language/semantics, languages only really take off because of a "killer app"
use case where they are required. Once that's in place, tooling is built to
make it much easier to complete projects in.

As a few examples: Objective-C was only popular for years because it was
_required_ to write iOS apps. Ditto JavaScript being the only way to write for
web. Ruby only got popular after Rails. C++ was the blessed way to write for
Windows in the 90's. Java had a giant marketing budget, "write once, run
everywhere," and was looking to be the best way to write for the web (lol
applets). This isn't a perfect explanation, but in many of these cases, it
wasn't about eager-vs-lazy, control flow constructs, variations in type
systems, or anything related to what the language offered you, it was
primarily necessity to be on the platform of your choice.

After that, tooling evolved, and they became easier to write major projects
in. Why write a web app in Erlang when the JVM has every major templating
system, an implementation of CommonMark, several high-performance JSON
libraries, model validation, several mature build systems, and thousands of
Stack Overflow answers?

This makes it hard for languages like Crystal or Nim to take off, but ON TOP
OF THAT Prolog is asking its devs to completely change how they approach
programming.

What would it take to make Prolog take off? A killer app. Which, in the 80's,
looked like it was AI :-p

~~~
protomyth
PHP's killer app was that it was easy for a System Admin to install on Apache
and easy for a programmer to upload something that worked.

~~~
zmonx
... for a quite generous definition of "worked".

In comparison, writing web applications with SWI-Prolog is quite safe also
thanks to the powerful quasi-quotation mechanism.

~~~
nickpsecurity
"... for a quite generous definition of "worked"."

Barely. All kinds of people learned it quickly. They built web applications.
It became a dominant web, application language. The momentum led to many
improvements in its ecosystem and deficiencies. Prolog failed to do... any of
that at PHP's scale.

~~~
zmonx
A language like PHP greatly increases the chance of security problems. There
is ample evidence of such issues in practice. This is one consequence of the
quite low-level way to reason about the available data, and a class of
problems that does not arise so easily in Prolog.

This is just one of many instances where barely working solutions are used,
partly stemming from a lack of alternatives at that time. Robust web
frameworks are only now becoming gradually available in Prolog!

~~~
nickpsecurity
PHP wasn't designed for secure web applications. Most of its users don't care
about that. It thrives anyway. So, this isn't a failure of PHP. On contrary,
the author cranking it out quickly might have been a reason for success.

Now, someone wanting secure apps might not want PHP. They traditionally went
with "safe" languages such as C# or Java whose runtimes were full of 0-days.
They might find Ada, Component Pascal, or Rust with a web framework helpful.
Even enterprise sector hasn't been writing most web pages is Ada, though. ;)

~~~
zmonx
Why are you downvoting what I wrote? You are arguing against statements I did
not make.

PHP worked for many people in what I can only consider a quite generous
definition of "worked", in tandem with countless security problems that arise
almost necessarily from its low-level data representation. I am not arguing
that this has impeded its adoption, that most users care about this, or that
it does not "thrive". These are _not_ signs that it works in the way I prefer
software and languages to work. In particular, for writing secure web
applications, I cannot recommend PHP.

In the future, I expect to see more and more Prolog web applications. The
necessary frameworks are now becoming available, with much better safety
properties.

~~~
nickpsecurity
You just repeated the statement Im arguing against: "generous definition of
worked." The goal of PHP was to help people, esp non-experts, quickly build
web sites. People off all skill levels managed to build web sites that did
what they intended in the intended use case. As in, PHP worked for the exact
thing it was designed for. It also went beyond that by getting massive
adoption by people cranking out too many sites go count. Its success at its
goal is legendary in a good or bad way depending on who you ask.

Next, you talk about the preference for secure, web apps. Being a high-
assurance, security engineer, I'd expect you to immediately start talking
about Ada, Opa w/ modified back end, SWIFT on SIF, Ur/Web, Haskell with secure
framework... languages that are systematically dedigned to either make classes
of vulnerabilities impossible or reduce them greatly. Also, esp Ada or SPARK
whose low-level libraries are written in same language for as much safety as
possible. Instead, you counter insecurity of PHP use by recommending a Prolog
not designed for security with low-level components probably written in C or
C++ since most Prologs are. It's probably gotten almist no pentesting to knock
out low-hanging fruit either. If those are true, then that's highly
hypocritical that you'd smear PHP while recommending something so insecure or
uncertain in its security.

Far as downvotes, it was because you made a bogus claim about PHP's success
with no substantiation. I certainly didnt downvote you cuz Im anti-censorship,
voted to eliminate downvotes on Lobsters, and it's impossible to downvote a
person replying to you. Check that claim by looking for downvote option next
to my name. I instead prefer to counter bullshit with facts in actual
comments. Also, with citations when I have time. As is clear by this one.

~~~
zmonx
Thank you for your explanation! I do not in the least dispute that the goal of
PHP was to help people, or that people managed to build web sites for the
intended use cases. In fact, if one of PHP's goals was to allow a great number
of unintended security flaws in user programs, then this was also splendidly
achieved. Personally, I only cannot bring myself to call a site with security
flaws "working", and when using PHP, these flaws are simply more easily made
than with Prolog in my experience. Note that I need not even go as far as
making any statements about particular implementations of Prolog or PHP, only
about user _programs_ written in the two languages.

Please also note that I cited quasiquotations as one important advantage of
Prolog. As for citations, the most relevant publication for this feature is:

Wielemaker, J., and Hendricks, M., _Why It’s Nice to be Quoted: Quasiquoting
for Prolog_
[https://arxiv.org/pdf/1308.3941.pdf](https://arxiv.org/pdf/1308.3941.pdf)

This feature lets you easily build _safe_ template engines in Prolog. Please
let me know what you think, if you have time. I am in fact frequently looking
for a pentester when building Prolog-based websites, are you interested in
such a project?

~~~
ScottBurson
Having done some work on static analysis of PHP applications, I agree that the
language is very poorly designed. It seems the designers add any feature that
they think will make it easier to write code, regardless of its effects on
readability or security. It's an ongoing problem, too. One might have had some
sympathy for an inexperienced language designer who pushed something out into
the world because he thought it was cool, but then when people pointed out the
problems with it, studied language design and learned to make better
decisions. That's not happening with PHP; even some relatively recent design
decisions are just mind-bogglingly bad. I am particularly frustrated by the
choice, a few years ago, to remove the requirement that arguments being passed
by reference be marked with an '&' at the call site (as well as on the
function parameter receiving the reference). Since in general you don't know
until runtime what function is called at a variable call site (e.g.
'$f(...)'), you can't tell by looking at such a call which arguments, if any,
are being passed by reference!

But, all that said, I think you can write an unsafe library or framework or
app in any language. In fact I recall a vulnerability in a widely-used Ruby
library in which one of the API functions normally expected some kind of
object, but if you passed it a string instead, it would call 'eval' on it for
you and use the result. This "helpful" behavior was not documented.

My point is that there's more to educating the masses about writing secure
code than just telling them not to use PHP.

~~~
zmonx
Thank you for this! Interestingly, the cases you mention _cannot arise_ in
Prolog, because Prolog terms are _never_ evaluated implicitly. They are just
terms, and you write predicates that reason over them. In pure Prolog, there
is no way to pass something "by reference" either.

If you are determined enough, you can definitely write an unsafe library or
app also in Prolog, and security mistakes are also routinely found in Prolog
implementations, just as in PHP or Java implementations. The main point is
still though that a large class of security issues that _easily_ arise in PHP
user programs by one of the ways you mention is far, far less likely to occur
in Prolog programs, due to the more direct, symbolic way you reason about data
in Prolog, and additional mechanisms such as the mentioned quasiquotations
which allow safe embeddings.

~~~
nickpsecurity
" The main point is still though that a large class of security issues that
easily arise in PHP user programs by one of the ways you mention is far, far
less likely to occur in Prolog programs"

This is true. While we're at it, I think it's worth bringing up that the most
powerful use of Prolog is embedding it in a LISP that is "batteries included."
One like Racket. That way, one can use a safe, easy-to-analyze, functional
style for most of the application, one or more DSL's for the templating (esp
HTML), and Prolog operating on LISP structures when Prolog is best thing to
handle it with. Alternatively, Shen uses something like Prolog as its type
system so you can hand-roll a custom, type system for each component which
might include security properties.

Far as good design, web, and security-oriented, the best I've seen is Opa
language for doing that plus being productive.

[http://opalang.org/](http://opalang.org/)

Too bad they moved the backend to Node. Probably to latch onto an ecosystem
getting momentum which is a lesson from Worse is Better philosophy. Most IT
tech that didn't disappeared into history at some point. I'd have preferred it
be Go if one of the new, popular things given its fast, simpler, and safe
enough. Hell, if libraries aren't a concern, they can even output safe subset
of C with all the checks enabled like Pieter Hintjens did with iMatix DSL's.

~~~
ScottBurson
I thought Opa looked very interesting when I first heard about it, but I don't
see much recent activity on the GitHub repo. Is it still alive?

~~~
nickpsecurity
I didn't even realize the last blog post as Sep 2013:

[http://blog.opalang.org/](http://blog.opalang.org/)

Hell, it might be dead. I'll have to email them some time this week to find
out what's up. Fortunately, it's open-source so others can pick up where they
left off if they want. Or do a clean-slate work with similar capabilities.

------
marcosdumay
For me, what killed it was the fun of making a simple change to your program
and due to a single character mistake insert a bug that turns its run time
from O(n) to O(e^e^n).

Besides, deep first recursive searches are easy to write and almost never work
well in practice, so even the problems that are greatly represented in Prolog
either do not get efficient binaries from the existent Prolog compilers or are
easy enough to write in another language that little is lost on the transition
(often both).

That said, I do think search based programming is underrated. There ought to
be some representation for theorem resolvers that is good for general purpose
programming. It's just that nobody found it yet.

~~~
tom_mellior
> There ought to be some representation for theorem resolvers that is good for
> general purpose programming. It's just that nobody found it yet.

There are some nice examples of search-based programming in Z3 (using the
Python API) in [https://yurichev.com/writings/SAT_SMT_draft-
EN.pdf](https://yurichev.com/writings/SAT_SMT_draft-EN.pdf) , if that is along
the lines of what you meant.

~~~
marcosdumay
That's cool. Although the syntax is very specialized, I never though about
approaching general purpose search from a SAT solver.

------
athom
Oddly enough, I was just recently trying to play around with the PortableApps
package of SWI Prolog, available here:

[https://portableapps.com/apps/development/swi-
prolog_portabl...](https://portableapps.com/apps/development/swi-
prolog_portable)

It's about the ONLY PortableApp that offers any kind of program development
capability beyond text editing, that I could tell. No compilers, no
interpreters outside of this and a couple of SQLite packages. Anyway, I pulled
this one down, fired it up, and... no worky. I got a console, theoretically I
could execute commands, but try and access the help or docs, and it bails out
with an error, telling me xpce can't be loaded, because load_foreign_library/1
is not defined? At least half the menu commands failed with the same error,
closing out the app in the process. Basically, the app is impossible to use.

So, there's my answer, one that can be applied to many otherwise promising
languages. Any system looking to gain traction really needs to go out of its
way to Just Work; to make itself readily available, easily installable,
immediately functional, and with clear documentation right at hand. You can
carry on 'til you're​ blue in the face about lazy programmers unwilling to
learn a simple build-and-install process, but with the ready availability of
other environments that generally Just Work, there's really no excuse. At
least, that's how I feel about it.

~~~
bsznjyewgd
But why try the "PortableApps" package of a program that isn't listed on that
program's homepage instead of using that program's own executable installer
listed on its homepage?

Is it not possible that this "PortableApps" package broke the program?

------
gtycomb
It’s about 15 or so years ago I tried Prolog in an application for analyzing
features of images. I remember two things from that – 1. Even though
concurrency is elegantly described through guards, implementation turned out
to to be not that easy, 2. You have to bypass the beauty of pure logical
statements in practice (for example see the 'Craft of Prolog' by Richard
O'Keefe on optimizing Prolog code). Once we get to this level of writing
Prolog code, you find other standard languages and libraries more competitive
and practical.

------
hendzen
When I tried to use SWI prolog for a toy-task, it failed miserably when
dealing with facts that contained numeric expressions. I think if a variant of
Prolog was paired with an SMT solver (e.g. Z3) it would be much more relevant
today.

For example, when dealing with bitemporal data (common in finance) you might
have a set of facts with two date range attributes. Lets simplify by saying we
have a set of facts each having a start date and end date. Here is some non-
working Prolog that could work if there was such a capability.

    
    
      entity('TimeWarner').
      ticker(entity('TimeWarner'), 'TWC', date(1999-01-01), date(2014-04-31)).
      ticker(entity('TimeWarner'), 'AOL', date(2014-05-01), date(9999-01-01)).
      current_at(ticker(entity(_), _, Start, End), T) :-
        T @> Start,
        End @> T.
    
      -- find current ticker for Time Warner
      current_at(ticker(entity('TimeWarner'), _, _), date(2017-05-29)) 
    
      -- SWI prolog can not unify the above clause!
    

(The code above is semi-pseudocode - but I did try and fail to make this work
some time ago)

Now, it turns out that this sort of exists already, it's called Answer Set
programming. There is one implementation out there [0] - but I didn't feel
like dredging up an old research project.

[0] - [http://potassco.sourceforge.net/](http://potassco.sourceforge.net/)

~~~
chielk
I simplified your notation a bit and added some slightly silly predicates, but
this works:

    
    
        ticker('TimeWarner', 'TWC', date(1999-01-01), date(2014-04-31)).
        ticker('TimeWarner', 'AOL', date(2014-05-01), date(9999-01-01)).
        
        transform_date(date(Y-M-D), R) :-
            R is Y * 416 + M * 32 + D.
    
        after(Adate, Bdate) :-
            transform_date(Adate, A),
            transform_date(Bdate, B),
            A @> B.
        
        current_at(Name, C, Start, End, T) :-
            ticker(Name, C, Start, End),
            after(T, Start),
            after(End, T).
    
    
    
        ?- current_at('TimeWarner', C, S, E, date(2017-05-29)).
        C = 'AOL',
        S = date(2014-5-1),
        E = date(9999-1-1).

~~~
hendzen
Thanks - this is great. I stand corrected!

------
gillh
Netsil's stream-processor is programmed using Datalog, which is a subset of
Prolog.

Our architecture/use-case: At Netsil, stateful packet processing pipelines are
written in declarative rules and materialized tables are backed by SQL
compatible embedded in-mem DB. Tuples are executed in parallel and parallelism
is controlled by specifying context constraints in rules (e.g. packets within
same TCP flow should be processed in order). Further, Datalog workflows are
distributable by providing "location specifier" in rules -- i.e. Tuples and
attributes serialize to protocol buffers and can be sent/received over ZMQ.
Also, the materialized tables in Datalog can be made to sync up with
Zookeeper, allowing distributed stream processors to do service discovery and
so on. It's a pretty sophisticated runtime/compiler, written primarily in
C/C++ for optimal performance. The underlying runtime uses a combination of
Intel TBB and Boost ASIO.

We are in general big fans of declarative approaches as they have saved us a
lot of time, allowing our small team to leapfrog the competition. You can
learn more about our architecture here: [https://netsil.com/blog/listen-to-
your-apis-see-your-apps/](https://netsil.com/blog/listen-to-your-apis-see-
your-apps/)

Disclaimer: I am co-founder of Netsil (www.netsil.com).

------
moomin
I'd argue it can't be done. It basically has features that are best
implemented as a library. In fact, the many kanrens (including Clojure's
core.logic) demonstrate the effectiveness of this approach. Meanwhile, stuff
like GPU-accelerated ML have supplanted it in the natural language processing
arena, and functional programming has become the paradigm of choice for
theorem provers like Agda.

~~~
killin_dan
Do you know very much about GPUs? Would but be viable to implement a kanren on
top of cuda or something like that? Wouldn't that lend kanren insane
performance gains?

~~~
convolvatron
not too surprisingly, a lot of logic programs don't parallelize very well at
all because of very linear dependencies (control flow).

and some do a lot of largely independent but very regular work that would
execute quite well on a simd/vector/smt array.

people have come up with some tricks to map control flow into simd (like some
really cool parser tricks), but i think in general those have regimes where
they have sub-serial performance.

so maybe? if you had the magic compiler? or you provided some manual
annotation support? or a robust ffi?

for sql, which has a much more limited footprint, there's been some cool
vectorization work.

------
protomyth
Prolog never had the SQL moment. SQL had IBM, Oracle, and relational databases
to back it up and propel it into popularity. Prolog just never had that
application. I also believe that the Japanese Fifth Generation Project's
failure did a bit to harm the idea of a mainstream Prolog. I was very
interested when Borland released Turbo Prolog, but it didn't quite last that
long. It also, in its early days, suffered from a bit of Smalltalk vendor
syndrome.

..and, sadly, it didn't look like C

// strangely Prolog is listed as a spelling error by Firefox...

------
danharaj
Prolog has a beautiful, powerful idea at its core: Resolution. Datalog shines
because it doesn't try to overreach and focuses on making this core nimble and
expressive in a domain excellently suited to resolution. Prolog tries to be
general purpose and is all the worse for it.

Eventually the ideas in Prolog will make their way into a general purpose
language where the relationship between the logical components and the
algorithmic components of a program is harmonious instead of a constant
conflict.

------
miclill
This is opinion but I think the problems you can express well with a language
like prolog are quite special. The problems programmers need to solve every
day are better expressed by a language that's closer to human languages. How
would you write in prolog that you want it to serve a website? Of course this
is possible but probably not in an idiomatic way. Furthermore like with
functional languages the performance of the program is harder to predict.

~~~
cronjobber
> How would you write in prolog that you want it to serve a website?

Here's one approach: [http://www.swi-
prolog.org/pldoc/man?section=pwp](http://www.swi-
prolog.org/pldoc/man?section=pwp)

Scroll down for examples. You might disagree, but I think the fit between
Prolog semantics and expanding XML templates is surprisingly natural.

------
BjoernKW
It's difficult to get started with Prolog beyond toy examples. Prolog was
originally designed for creating linguistic models for use in NLP. Even for
this original purpose it isn't exactly easy to use.

When it comes to mundane tasks such as opening a file and reading its contents
as a string or accessing databases, things get even more difficult.
Technically, this is all possible with Prolog, too. It's just not exactly fun
to do so.

~~~
zmonx
First of all, I fully agree that it is hard to start with Prolog initially.
However, let us take a look at these particular examples:

As to _opening a file and reading its contents as a string_ :

I find it best to use Ulrich Neumerkel's library(pio) to accomplish this task.
Importantly, this lets you apply a DCG to a file in a _pure_ way. I start with
a DCG that simply describes a _list of characters_ :

    
    
        content([]) --> [].
        content([C|Cs]) --> [C], content(Cs).
    

I save this in content.pl, just to have a file to try. I can now apply this
DCG to the file contents with phrase_from_file/2:

    
    
        ?- phrase_from_file(content(Cs), 'content.pl').
        Cs = [c, o, n, t, e, n, t, '(', '['|...] .
    

Thus, I have read the file contents as a _list_ of characters, which I can
easily convert to anything I want with other predicates.

As to _accessing databases_ : That's quite straight-forward too, in particular
if we take into account the following: If you are really using Prolog
professionally, then typically Prolog _is_ the database. You simply assert
facts, and retrieve them by _querying_ the built-in Prolog database.

Personally, I find Prolog queries much more convenient and also more
expressive than SQL, and great fun too.

~~~
Arcsech
The problem is "Prolog is the database" is that there isn't a great solution
for persisting that database, which is usually what people mean when they talk
about databases. Sure, for SWI-Prolog there's Persistency but that a) doesn't
help you if your data doesn't fit in memory, and b) doesn't give a lot of the
same guarantees as something like Postgres about durability through sudden
failures (as far as I can tell, the docs sure don't mention it). It's closer
to SQLite than a database you'd use for a production web app.

~~~
zmonx
Yes, I agree with this. In SWI-Prolog, in addition to library(persistency),
there are already some published results on transaction support for the
internal database, which will give you some features that facilitate such use
cases. This is already available and in fact also running for production web
apps, but currently only for the RDF database. It is true that if you need
more advanced functionality that dedicated database systems readily give you,
then you have to wait until such features become available in SWI-Prolog, pay
for their implementation, or resort to using an external database for which
there often are bindings.

------
carvalho
Prolog is used in IBM Watson, Datalog, and AFAIK in Windows OS.

Prolog is not so popular for general purpose computing since: compilers are
inconsistent, compatibility problems, difficult debugging, high maintenance
costs, few experts, steep learning curves (my professor joked that the more
computer science the student is exposed to, the harder is the mental switch to
Prolog).

Prolog remains great for education on logic, NLP parsers, recursion.

------
gonmf
As someone who has quite the extensive experience with Prolog, I can best
summarize that there are some types of programming problems at which it
excels: deduction, ordering, discrete constraint problems, etc; and at
everything else an imperative language is often simpler to use to achieve the
same end result.

------
nickpsecurity
Look into Mercury language for a take on something that might be more
acceptable by mixing logical and functional:

[https://www.mercurylang.org/about.html](https://www.mercurylang.org/about.html)

~~~
vram22
Prince XML, a software tool to generate PDF from HTML and CSS, is written in
Mercury.

[https://en.wikipedia.org/wiki/Prince_(software)](https://en.wikipedia.org/wiki/Prince_\(software\))

From above page:

>Prince was developed using the Mercury functional logic programming language.

------
dkersten
I'm no expert, but I've tinkered with prolog in the past and with Clojure's
core.logic more recently and in my opinion it's because the part of my
problems that would be a good fit for prolog make up only a small part of the
solutions that I write to solve them. For this reason, something like
core.logic is much more interesting and useful because it means I can express
the part that is well suited to logic/constraint programming in "prolog" and
the parts that are not well suited, can be written in another language more
suited to those tasks.

For example, I can write some code in clojure, that, for example, implements a
UI which then calls core.logic to do some processing, which then calls some
clojure to pull the logic data from a database. If I wanted to use prolog, I'd
have to do something like: (other language -> ffi -> prolog -> ffi -> other
language) which is usually too much effort for me to bother.

------
inputcoffee
I thought the same thing till I tried to program in it and I immediately
understood.

It is not intuitive, and most programs aren't logical problems in the sense
that the prolog can solve. It is highly specialized.

It belongs to an era -- and this era isn't "over" \-- when the primary manner
of solving AI was symbolic.

------
zmonx
As to the first question: There are several reasons for this. One is rather
inherent and can be understood by considering the following analogy:

Java, C, and many other programming languages are like chess: There are many
syntactic rules, and by learning them, you already obtain a rough overview of
what you can do in principle. You try out these constructs, and get a sense
that you have accomplished something, even if it is rather worthless, and more
complex tasks are extremely hard to carry out successfully in these languages.

Prolog is more like Go: The syntax is very simple, and there is essentially
only a single language element, the _logical rule_. This means that even if
you know, syntactically and semantically, almost everything about the
language, you have no idea what to do at first. This can be rather
frustrating. From this, beginners easily arrive at the misguided conclusion
that the language is useless, or restricted to very specific applications. But
it only means they have not grasped its true power and flexibility! Getting to
the core of Prolog is hard, and requires systematic guidance.

This inherent difficulty is frequently compounded by a rather ineffective and
_outdated didactic approach_ which, at its worst, stresses difficult and
mostly superseded procedural aspects over more important declarative
principles and more modern solutions like constraints. This easily gives the
misguided impression that the language is rather imperative and limited in
nature, and again causes many students to dismiss it due to their wrong
impressions.

A third reason is found in the _implementational complexity_ : From a user's
perspective, a major attraction of Prolog is its _ease of use_ due to the
syntactic simplicity, powerful implicit search mechanism, generality of
predicates etc. which are features that are rather specific to logic
programming languages. The complexity of all this is shifted to the
implementation level: In order to make all this both powerful _and_ efficient,
the implementation must do many things for you. This means you need, among
other things and in no particular order: an efficient garbage collector, JIT
indexing, a fitting virtual machine architecture, a fast implementation of
unbounded integers, rational numbers, good exception handling, ISO compliance,
many goodies like tabling, an efficient implementation of constraints over
integers, Boolean variables, Herbrand terms etc. Most of these topics are even
now still subject of _active research_ in the logic programming community,
with different advantages and trade-offs. Implementing an efficient Prolog
system is a project that _easily_ takes 30 to 40 years. In fact, we are only
now getting to the point where systems become sufficiently robust and feature-
rich to run complex client/server applications for months and years. In such
complexities, you find the answer why Prolog isn't more popular _yet_. It has
simply taken a few decades to implement all this in satisfactory ways, and
this work is still ongoing. In my view, Prolog is now _becoming_ interesting.

To the second point, Prolog already _is_ a great general-purpose language. You
can use it for almost all applications that are currently written in Java and
Python, for example. Of course, there are always some features that are worth
adding on top or via extensions, and certain tasks would benefit from this.
For example, you can add extensions for type checking, and for fast arrays.
Various Prolog implementations are already experimenting with such extensions.
Many extensions can in fact be implemented via term and goal expansion, a
facility that is analogous to macros in Lisp, or via simple reasoning over
given programs.

~~~
bordercases
Good post, in particular splitting out the differences between explicit syntax
vs expressive syntax. I myself am quite fond of expressive formal systems, but
equivalently useful explicit systems are much easier to pick up even if their
ruleset is larger. One has hack-y corner cases but generally keeps you on the
rails, the other has the hacks _as the rails_ and expects you to not fuck up
where you're going. Or something like that.

~~~
zmonx
Thank you! I found the following chart useful:

    
    
      *) machine and assembly languages: simple syntax, simple semantics
      *) procedural languages: complex syntax, AST not available, many language constructs
      *) Smalltalk, LISP, Prolog: AST available, few language constructs
    

Source:

[http://www.complang.tuwien.ac.at/ulrich/prolog2009.pdf](http://www.complang.tuwien.ac.at/ulrich/prolog2009.pdf)

~~~
bordercases
Well now I must definitely use Smalltalk!

~~~
zmonx
It's definitely worth a look! Richard O'Keefe, one of the most highly regarded
and accomplished Prolog programmers, even wrote his own Smalltalk
implementation too:

[http://www.cs.otago.ac.nz/staffpriv/ok/software.htm](http://www.cs.otago.ac.nz/staffpriv/ok/software.htm)

------
nmca
One of the worst things I found during my prolog courses was that authors
seemed to conflate "shorten" and "simplify". We had whole exercises dedicated
to taking a readable chunk of code and turning it into some godawful one
liner.

------
gpcz
You can answer this question yourself: simply figure out how you'd implement
certain types of programs in Prolog. For example: an operating system, a Unix
command-line tool, a video game, etc. You'll quickly shake out deficiencies.

~~~
zmonx
These are good questions! As a simple control, I have asked myself these
questions with Java in mind, which enjoys notable popularity.

Would I write an operating system in Java? No. A Unix command-line too? No. A
video game? Probably not.

In my view, this casts some doubt on the test's adequacy to answer the initial
question. In the concrete case of Java, I think marketing and other influences
also played important roles. It could be possible to apply these advantages to
Prolog too.

~~~
jorams
You are not asking the same questions. The question is _how would_ , not
_would_. While I'll admit writing an operating system in Java is non-trivial
(thinking of kernel-level programming here), writing a command-line tool or a
video game is pretty simple. You main method receives command line arguments,
so that part is covered, and for games you do pretty much what you would do in
any other language.

~~~
zmonx
Thank you! Indeed, the question was "how" would I do it, so let us consider
it:

Operating system in Prolog: Non-trivial, i.e., like in Java. Command-line
tool: Pretty simple: My main predicate receives command line arguments. There
are countless such examples already, included in the SWI-Prolog distribution
(for example). And, as you say, for games I would do pretty much the same as
in any language also in Prolog.

In my view, this still leaves the same doubt about these questions: Can we
distinguish Java from Prolog in any way by answering them?

------
scottlocklin
I've never messed around with it beyond toy problems, but I recall Norvig
saying in one of his books that it was trivial to code up NP hard problems in
Prolog and other logic constraint languages without realizing that you did so.

------
tmaly
I have used Prolog a few times in a profession setting. When you are using it
for the right problem, it is perfect.

To use it in a more general purpose sense, I think you need a couple of
things.

First, you need some really great training and or books showing practical
examples as well as how to overcome common issues with performance.

Second, you need more people contributing the some of the open source options
like SWI Prolog.

Third, I think you need more ready to use bindings for the popular languages
out there. SWI Prolog provides a C interface, but if you had an interface to
say Node, Go, Rust etc that was simple to install with some good examples, you
could reach more people.

------
killercup
I don't know about general-purpose, but I've seen Prolog implementations for
specific logic problems. Most recently, chalk [1], a Prolog interpreter
designed to be used in the Rust compiler's trait system. So I wouldn't say
it's not popular, but the areas it's used in are probably not what most
programmers deal with every day.

[1]:
[https://github.com/nikomatsakis/chalk](https://github.com/nikomatsakis/chalk)

------
pedrorijo91
I would say the problem is pretty similar to why isn't Haskell more popular?

both have a different/specific (as in non-mainstream) thinking way, and it is
not easy to switch from common programming languages to these. and since it
isn't easy, most people don't go deeper on them

from a company point of view: if it's hard to find a good Prolog/haskell
developer, then they will be more expensive, so they stick with the common
Java/C/C#/Python/Ruby/JS stack

------
randomUser1122
I tried programming in prolog and read some introductionairy books. However,
no book talks about how you would define more complex 'types' objects. How
would you model the following domain in prolog:

Comment: Attributes: text, points

User: Attributes: name, emailAdress(as a struct of first part, domain, top-
level-domain)

Admin(a special user): additional Attributes: set of rights(can delete, can
hide, can modify)

Finally, there is an n-1 assocation between Comment and User and I want to
make some queries about this domain.

~~~
zmonx
There are several ways to do it. One straight-forward way is as follows:

We can represent _comments_ by facts like:

    
    
        comment_id_user_text_points(3, 1, 'hello!', []).
    

I do not know what exactly you mean by "points", so I have simply supplied an
empty list (fourth argument) in this case. Note that there is an ID for the
comment, and an ID for the user that posted the comment. Therefore, we say
that this is a _relation_ between users and comments and their text and
points, usable in all directions.

Each user can likewise be represented as follows, relating a unique ID to a
name and e-mail address:

    
    
        user_id_name_email(1, 'randomUser1122', [random,'ycombinator.com']).
    

For _admins_ , I can simply add additional facts, relating user IDs to
_rights_ like this:

    
    
        admin_id_rights(1, [delete,hide]).
    

Now, we can simply post _queries_ over these facts, such as:

    
    
        ?- user_id_name_email(ID, _, _), 
           comment_id_user_text_points(_, ID, Text, _).
    

and obtain, on backtracking, all comments for any user.

This is all completely analogous to how you would represent such data in any
database system. It's more convenient in Prolog though for several reasons.

~~~
randomUser1122
Wow, modelling it like in a relational DB is a great idea! Thanks. Your trick
of adding names of the properties like "_id_user_text" is neat. In the past, I
tried a similar solution like but I would always forget which property is at
which position.

How would you make sure that the rights of admins are only delete, hide, and
modify (and not e.g. walk, talk, chalk) ? If I use

    
    
      admin_id_rights(Id, Rights):- numeric(ID), sort(Right, SortedRights), subset(SortedRights, [delete, hide, modify]). ,
    

then I obviously have added all possible admins.

Moreover, how would you then 'create' objects without adding them with
asserta. Assume that all the user, admins, comments are written to a text file
which should be queried. I can easily read them into some nested compounds
with DCGs. However, I would like to create objects(e.g.like Java's new) to
check that they adhere to the contraints of my model.

~~~
zmonx
The naming trick makes clear what each position means: The order of arguments
follows that of the name's components. So, if the name contains id_user_text,
then the arguments are also in this order: ID of comment, ID of user, and the
text. This is a simple mnemonic technique I use for naming important
predicates.

As to your first question, we are now talking about (database) _integrity_
constraints. So I would first state which rights are admissible at all by
clearly defining what we consider a right. For example, in this concrete case:

    
    
        right(delete).
        right(hide).
        right(modify).
    

Next, I _describe_ the situation that an admin was inadvertently assigned a
"bad" (i.e., not actually existing) right:

    
    
        user_bad_right(ID, R) :-
             admin_id_rights(ID, Rs),
             member(R, Rs),
             \+ right(R).
    

Now, I can ask Prolog: _Are there any bad rights assigned_? I do this by
simply posting the most general query about this relation:

    
    
        ?- user_bad_right(ID, R).
        false.
    

I conclude: _No_ , there are no bad rights assigned.

As for _creating_ objects: This is a _good_ case of using the dynamic
database, i.e., predicates like assert/1 and assertz/1\. The database is very
good for frequently _retrieving_ information, but not good for frequently
_updating_ the information. This is a fitting situation: Comments are
presumably only posted once, and in that case, you can simply add such facts
to the database.

But you can of course also make all this explicit, and first construct a
_term_ of the form comment_id_user_text_points(3, 1, 'hello!', []), and then
reason about such terms (instead of reasoning about the asserted facts). Note
that this term looks exactly like the fact syntactically, due to the
homoiconic nature of Prolog. Therefore, you have many ways to reason about
your data. You can even write all such terms to an external file, and simply
consult all facts (and even rules) it contains by invoking consult/1
_dynamically_.

~~~
randomUser1122
Thank you for all you great tips. Do you know any good book(except Craft of
Prolog, Prolog for AI) or good code on github following this principle?

~~~
zmonx
Thank you for your interest!

Since Prolog is now gaining more traction, I am adding to my favourites all
Prolog links which I consider noteworthy or recommended reading. Please see my
profile for more information, and also for future updates.

~~~
kabowen
On GitHub, you may want to check out
[https://github.com/AppliedLogicSystems/ALSProlog](https://github.com/AppliedLogicSystems/ALSProlog)

------
cocktailpeanuts
You would probably realize pretty soon if you try writing anything meaningful
with Prolog.

In my experience Prolog is conceptually the coolest, but practically the worst
when trying to get anything done.

Basically, writing a program in Prolog is like solving a puzzle. Nobody wants
to solve an additional "puzzle" on top of their already existing problem they
set out to solve by programming. (Unless they're doing it for fun)

------
macintux
I attended, but can't claim much comprehension of, Chris Martens' talk on
logic programming at Strange Loop 2013. If you're interested in the world
beyond Prolog, worth a watch.

[https://www.infoq.com/presentations/linear-logic-
programming](https://www.infoq.com/presentations/linear-logic-programming)

------
mjn
Some previous blog posts on this topic, from a few years ago:

"Who Killed Prolog?" by Maarten van Emden.
[https://vanemden.wordpress.com/2010/08/21/who-killed-
prolog/](https://vanemden.wordpress.com/2010/08/21/who-killed-prolog/)

Posits that the huge hype put into it by the Japanese Fifth Generation
Computing Project, which it failed to live up to, essentially killed off
interest in the language, which it never recovered from.

"Why did Prolog lose steam?", a sort-of reply I wrote.
[http://www.kmjn.org/notes/prolog_lost_steam.html](http://www.kmjn.org/notes/prolog_lost_steam.html)

Posits instead that much of the low-hanging declarative fruit has been picked
off by other, more specialized languages, ranging from SQL to production-rule
systems to even LINQ, so Prolog no longer is the default go-to declarative
programming language.

------
nv-vn
Having tried Prolog for a problem that it's relatively well-suited for, I
found that all the advantages Prolog gives fall away very quickly. There's a
lot of finicking around with weird organization of your code just to get
things to work, despite being "declarative." For example, trying to rely on
libraries to solve parts of the problem for you can be really strange because
you can be 99% of the way to solving your problem, but not being able to
edit/inline that code will create problems. As an example, trying to use a
sorting function on an uninitialized list can't really do anything to help
you, but if you inline that same code it can fix it because you're declaring
properties of the list in-place.

~~~
YeGoblynQueenne
>> trying to use a sorting function on an uninitialized list

That would give you an error, and rightly so. You can't really expect to sort
what's not there. Or am I misunderstanding your comment somehow? I don't quite
understand what you mean by "inlining" and how that can help sort a list of
no-values?

~~~
nv-vn
The way Prolog is "declarative" is that it bridges the gaps between assertions
about the properties of a result and actions used to achieve those properties.
For example,

    
    
        p(X) :- sorted(X).
    

is saying both (the imperative) "p(X) = sort(X)" and (the assertive) "a sorted
X has property p(X)". To solve for P(X), one only needs to find an X such that
X is sorted. This makes it difficult to say: "I expect input that, when
sorted, has this property" because there is no clear meaning when X is
uninitialized. Yet if you expand the meaning you can become "more explicit"
about it and convince Prolog that what you're saying is true.

~~~
zmonx
To express "I expect input that, when sorted, has this porperty", you have to
use slightly more modern language features that are called _constraints_.

For example, let us _describe_ sorted lists of _integers_ :

    
    
        sorted([]).
        sorted([L|Ls]) :-
                maplist(#=<(L), Ls),
                sorted(Ls).
    

Here, I am using the CLP(FD) constraint (#=<)/2 that works correctly in all
directions, whether or not its arguments are already instantiated to concrete
integers. Such constraints are available in all widely used Prolog systems.
You can try the above in GNU Prolog, for example.

Now the point:

Exactly as you say, the predicate works for _concrete_ lists of integers that
are already given:

    
    
        ?- sorted([1,2,3]).
        true.
    
        ?- sorted([2,1,3]).
        false.
    

And _moreover_ , it also works if the integers are _not_ given, for example:

    
    
        ?- sorted([X,Y,Z]).
        Z#>=X,
        Y#>=X,
        Z#>=Y.
    

We can even ask for example:

    
    
        ?- sorted([X,2,3]).
        X in inf..2.
    

This means that _if_ this relation holds, than X is at most 2.

We can obtain concrete solutions with _enumeration predicates_. For example:

    
    
        ?- Vs = [X,Y,Z], sorted(Vs), Vs ins 1..3, label(Vs).
        Vs = [1, 1, 1], X = Y, Y = Z, Z = 1 ;
        Vs = [1, 1, 2], X = Y, Y = 1, Z = 2 ;
        Vs = [1, 1, 3], X = Y, Y = 1, Z = 3 ;
        Vs = [1, 2, 2], X = 1, Y = Z, Z = 2 .
    

And maybe most strikingly, we can also use this in the _most general_ sense,
where we ask: _Is there any solution whatsoever_? The system _generates_
answers in this case:

    
    
       ?- sorted(Ls).
       Ls = [] ;
       Ls = [_28] ;
       Ls = [_170, _176],
       _176#>=_170 ;
       Ls = [_1194, _1200, _1206],
       _1206#>=_1194,
       _1200#>=_1194,
       _1206#>=_1200 .
    

Note that all these considerations lead us to the conclusion that "sorted" is
a rather bad name for the relation, since it implies that "something has been
sorted" and thus encourages a rather _imperative_ view. A better name would be
ascending/1, denoting a relation that is true _iff_ its argument is a list of
ascending integers, whether or not they are already known.

------
domenico_c
In my opinion there are mainly three reasons why Prolog is not popular.

The reason is that declarative languages in general are not as immediate as
imperative languages. Nothing intrinsic about declarative languages
themselves, this has to do mostly with the fact that we are taught and we are
exposed to imperative languages first and then we hear about other more
"exotic" paradigms.

Second issue. In a sense, the elegance of the language has been the biggest
weakness. The academics loved to play with conceptual matters. A lot of effort
went into papers on semantics and mapping different types of reasoning but not
much into tools, IDEs, or compilers. The community didn't make enough
libraries, built the right abstractions and software engineering practice.
Every time you start a project in Prolog you are starting from scratch. Also,
the elegance of the language is the reason a lot of people approaching Prolog
get quite demanding. "It's logic programming so why do we have to use a cut?".
Yet most programmers have no problems with the quirks of C++ or Java.

The third one is Prolog hasn't found it's excellence area. C, Go, Scala, Java
all have their on strengths and scenarios where they are the best candidates.
Prolog would make in theory an excellent candidate for representing complex
domains based on rules, covering a module of a larger piece of software. It
would be perfect to represent the rules of a board game or the knowledge of a
chatbot, but for a number of reason that's no happening. How does the reasoner
scale with larger datasets? Will it be hard to manage? Is there an example of
something similar being attempted?

In my very personal opinion, as a community we should learn from these
lessons, take the best bits of Prolog and make something new. At Grakn.ai
([https://grakn.ai/](https://grakn.ai/)) we are working on a graph database
that uses an inference layer that is based on Prolog's resolution, maybe worth
having a look. The idea there is that Prolog maybe shouldn't become a great
general-purpose language but its bests parts must be used as a base for the
next advances in knowledge representation and reasoning.

~~~
zmonx
Grakn was also recently posted on HN:

[https://news.ycombinator.com/item?id=14471238](https://news.ycombinator.com/item?id=14471238)

In that thread, I show how you can express the sample relation in Prolog.
Maybe you can go into more detail, either here or in that thread, on the
advantages of Grakn over Prolog for such cases?

~~~
domenico_c
Someone from my team replied. Thanks for taking the time to start the
discussion on the comparison, we have a few people with a computational logic
background here and we plan to publish a blog post on the topic soon!

~~~
zmonx
Perfect, I am looking forward to reading the blog post! I hope it will also
mention Prolog as an important influence.

As to your second issue above: Please note that there are _many_ collections
and even entire books that describe _antipatterns_ of Java, C++ and many other
programming languages. In my experience, programmers from these communities
quickly learn to avoid these antipatterns. In the Prolog community, this
happens more slowly, but it does happen too. There are very good reasons to
avoid !/0 and other impure constructs in logic programs. In my view, the key
issue is to find and teach better constructs that should be used _instead_ ,
and the best alternative language constructs are still waiting to be
discovered.

In this spirit, I fully agree with you that we should keep Prolog's best
aspects, and extend them as far as we can into the directions we need.

------
FreeFull
Perhaps what is needed is a Prolog-derivative language which is nicer to use.
There is a number of declarative languages available, but my personal
favourite would be Picat [http://picat-lang.org/](http://picat-lang.org/) A
disadvantage of Picat would be though that unlike SWI Prolog, it doesn't have
any sort of package management system, and doesn't have a general means of
using FFI to call into C libraries.

~~~
zmonx
Picat is a very interesting development. Note though that it, at least
currently, omits some key features of Prolog such as the _homoiconic_ syntax,
and definite clause grammars (DCGs).

------
lolc
I couldn't find much use in Prolog when I tried it. At first it was neat how
you could express simple problems, then I learned how one used ! for
everything else. It felt like instead of working on a solution, I had to work
on what the solution isn't.

It's a very specialized system in my view, so there is no hope of it ever
becoming general-purpose. But maybe that's because I don't know enough of
Prolog.

~~~
zmonx
Have you been exposed to more recent research on Prolog language constructs?

In particular, I recommend the following publication:

[https://arxiv.org/abs/1607.01590](https://arxiv.org/abs/1607.01590)

if_/3 and other declarative predicates like dif/2 are more general
alternatives and likely good solutions in the cases you mention. They are
still quite recent, at least if we ignore the fact that dif/2 was even
available in the very first Prolog system, sometimes called Prolog 0.

------
YeGoblynQueenne
Prolog is already a general-purpose language. So is any Turing complete
language, by definition. Whether it's a "great" such language or not is kind
of a personal tastes thing.

As to why it's not more popular, I've thought about this very ofen and I don't
have an answer. What I know for sure is it's never going to become more
popular until people move on from that silly soundbite about its "general
purpose"-ness, which never made any sense to begin with.

People program "general purpose" stuff in languages that are much worse for
"programming in the large" than Prolog. Most of the big operating systems are
written in C, large swathes of game code is in some assembly language or
other, about 60% of enterprise code is in Java and most supercomputing code is
in FORTRAN fer chrissake. Not to mention, all of the internet is in
javascript, a language that was originally meant just for writing small
snippets of code to manage buttons and text fields and stuff. You're not going
to tell me that javascript is "general purpose"?

Prolog is already a general-purpose language. All you need to do is have a
look at the library section in the Swi-Prolog documentation. Besides the usual
suspects (constraint logic, tabling, lambdas and such and of course parsing
all possible text-based formats ever in time dt) we find a bunch of diverse
libraries:

An http package for all your client/server needs [1]

A library for opening web-pages in a browser in a system-agnostic manner [2]

A library for command-line parsing [3]

An RDF parser and a semantic web library

A package manager [5]

A random numbers generation library

A library for manipulating the Windows registry [7]

A library for solving linear programming problems [8]

A thread pool management library [9]

And a whole lot of support for a bunch of other stuff like corouting,
multithreaded applications, a profiler, terminal control, an ODBC interface,
an interface to Protocol Buffers, bindings to zlib, GNU readline, and so on
and so forth.

In what sense is all that not "general purpose"?

______________

[1] [http://www.swi-
prolog.org/pldoc/doc_for?object=section(%27pa...](http://www.swi-
prolog.org/pldoc/doc_for?object=section\(%27packages/http.html%27\))

[2] [http://www.swi-prolog.org/pldoc/man?section=www_browser](http://www.swi-
prolog.org/pldoc/man?section=www_browser)

[3] [http://www.swi-prolog.org/pldoc/man?section=optparse](http://www.swi-
prolog.org/pldoc/man?section=optparse)

[5] [http://www.swi-prolog.org/pldoc/man?section=prologpack](http://www.swi-
prolog.org/pldoc/man?section=prologpack)

[7] [http://www.swi-prolog.org/pldoc/man?section=registry](http://www.swi-
prolog.org/pldoc/man?section=registry)

[8] [http://www.swi-prolog.org/pldoc/man?section=simplex](http://www.swi-
prolog.org/pldoc/man?section=simplex)

[9] [http://www.swi-prolog.org/pldoc/man?section=threadpool](http://www.swi-
prolog.org/pldoc/man?section=threadpool)

~~~
dragonwriter
GPs issue seemed to be that it wasn't a great or popular language for general
use, not that it isn't a general purpose language.

~~~
YeGoblynQueenne
The question asked is "what would it take for Prolog to become a great
general-purpose language". That sounds like they think it isn't. If that
wasn't meant OK, but that's definitely what it reads like.

~~~
dragonwriter
Yes. The mistake is thinking "is not currently a great general-purpose
language" implies "not currently​ a general-purpose language".

~~~
YeGoblynQueenne
Sorry, but that's not a mistake. That's the common-sense reading of the title.
Your reading is much less likely.

~~~
dragonwriter
Your reading makes the word "great" superfluous. Its not "common sense" to
read a qualifier out of the question asked.

~~~
YeGoblynQueenne
That _literally_ is what common sense is _all_ about.

------
usgroup
If you're into Clojure et al or at least datomic you've probably used some
subset of prolog (qua datalog).

Clojure also brings with it logic and relational programming which is likely
the go-to choice of the Clojurist for expressing work-flow or permissions
management type problems. Not exactly Prolog but it's the same difference.

------
harperlee
Is there a particular book that covers Japan's 5th generation fiasco, from a
technical point of view?

~~~
zmonx
I once asked a retired Japanese computer scientist why the 5th generation
project had failed. He said: "What do you mean 'failed'? All my former
colleagues who had worked on this project went on to become full professors!"

Also, I once attended a talk by a Japanese researcher who was intimately
involved in the project. One significant phenomenon at that time was that
commodity hardware was progressing much faster than had been anticipated, in
the end eclipsing the specialized designs that were being worked on.

There are other reasons too, and here I can only say that Prolog as it is
today had very little to do with the outcome. In fact I think this would be a
great follow-up question to the present discussion!

~~~
nickpsecurity
"One significant phenomenon at that time was that commodity hardware was
progressing much faster than had been anticipated, in the end eclipsing the
specialized designs that were being worked on."

This is exactly what happened. A slow language like Prolog on OK hardware that
accelerates it can't compete with a fast language like (not-Prolog) on highly-
custom, top-of-the-line hardware that accelerates it. It can't in the general
case and plenty times not in the special case. Now, that was when Moore's Law
was in full swing. There's potential now for that pendulum to swing in reverse
for something like this.

------
garrybelka
1\. 2\. There were too many fully incompatible dialects of Prolog. I recall
Lisp-like Micro-Prolog. Turbo

------
seanwilson
I've wanted to use Prolog in JavaScript and Java projects before but I could
never find robust Prolog implementations for either. I wouldn't want to use
Prolog for a GUI or be tied to binary implementations of it but it has its
uses.

------
lowbloodsugar
Because its only first order so its really tedious. So you can say that if a >
b and b >c then a > c, but you can't say if a op b and b op c implies a op c
then op is transitive.

~~~
zmonx
This is not the case: Prolog has several _higher order constructs_ like the
call/N family of predicates, maplist/[3,4] and foldl/N.

Your particular example of transitive relations is one of the most elementary
examples that are typically solved in basic Prolog courses as exercises, when
defining _reachability_ : B is reachable from A if there is an arc between A
and B. Transitivity can easily be defined by a rule, as you correctly mention.
For instance, let us take your example:

    
    
      fact(a > b).
      fact(b > c).
      
      transitive(A, B) :- fact(F), F =.. [_,A,B].
      transitive(A, C) :- fact(F), F =.. [_,A,B], transitive(B, C).
    

Here are all solutions:

    
    
        ?- transitive(X, Y).
        X = a,
        Y = b ;
        X = b,
        Y = c ;
        X = a,
        Y = c ;
        false.
    

Note that the operator ">" is _not_ mentioned in the definition of
transitive/2\. Instead, I am using the meta-predicate (=..)/2 to reason about
_all_ functors that can arise, making this a quite general definition of
transitive relations.

We can also reason explicitly about the relation, by making the functor (which
may, or may not be defined as an _operator_ ) available as a predicate
_argument_ :

    
    
      transitive(Op, A, B) :- fact(F), F =.. [Op,A,B].
      transitive(Op, A, C) :- fact(F), F =.. [Op,A,B], transitive(Op, B, C).
    
    

Now we can ask queries like:

    
    
        ?- transitive(Op, X, c).
        Op =  (>),
        X = b ;
        Op =  (>),
        X = a ;
        false.
    

and also in the other direction:

    
    
        ?- transitive(Op, a, Y).
        Op =  (>),
        Y = b ;
        Op =  (>),
        Y = c ;
        false.
    

And we can also ask in the most general way possible, where all arguments are
fresh variables.

------
JabavuAdams
Because it's more appropriate as an embedded DSL, or low-level on which to
create a DSL, than a general programming language?

------
jeffdavis
You don't use a _language_ , you use a _compiler_ and a _runtime_.

Maybe prolog has just not found the right context to run in?

------
foolong
Take a look at ASP (Answer Set Programming) For me it worked a lot better than
prolog

------
dennis714
IMHO, SAT/SMT solvers does mostly the same, so why would you designate
separate PL for this task, when you use these tools or libraries?

~~~
zmonx
SAT is about a very special case of logic, namely _propositional_ logic, where
every variable stands for exactly one of only two possible truth values.
Finding satisfying assignments in propositional logic is indeed already a
computationally hard task, and it is good that we have efficient SAT solvers
for such use cases, allowing us to solve a large variety of combinatorial
problems nowadays.

However, Prolog lets you tackle not only propositional logic, but tasks that
go far beyond this, belonging to a logic called classical _first order_ logic,
of which propositional logic is only a subset. In first order logic, we reason
about predicates _between_ terms, and this lets you tackle much more complex
tasks, far beyond what SAT/SMT solvers can solve for you.

In fact, first order logic is so powerful that it lets you describe everything
you can _in principle_ perform with a computer. It lets you describe how a
compiler works, for example. Or how numerical integration works. And all other
computations you have ever seen computers perform.

In short, Prolog is a programming language, and can in fact even be used to
_implement_ a SAT solver, which is impossible to do with just a SAT solver.
Many Prolog implementations even _ship_ with a SAT solver as one of their
libraries.

There are also even higher-order constructs in Prolog, such as predicates that
let you invoke _other_ predicates, making programming in Prolog very
expressive and convenient.

~~~
ScottBurson
> first order logic is so powerful that it lets you describe everything you
> can in principle perform with a computer

Not quite sure what you're referring to here, but induction schemata seem to
be a notable exception. There's a reason higher-order logic is often preferred
for software verification.

I guess FOL is adequate if you're allowed to have an infinite number of
axioms, but that doesn't seem very satisfying (pun intended).

~~~
zmonx
I am referring here to the fact that first-order logic is sufficiently
expressive to describe how a Turing machine works, making FOL Turing-complete
and thus, as a special case, making every computation you can carry out on a
computer expressible in FOL, as a first-order formula that is satisfiable
_iff_ the TM accepts the input.

------
danmaz74
Short answer: because intelligence isn't about solving propositional logic.

