Learn Prolog Now
learnprolognow.org
learnprolognow.org
[Edit] - funny, someone just posted this other tutorial to HN too, haven't done it yet but looks fun and educational, it's a murder mystery! https://xmonader.github.io/prolog/2018/12/21/solving-murder-...
Hyperfiddle is a paradigm shift on the front end too, using the same concepts, imagine real time GraphQL on steroids where the query doesn't need a horrible SQL translation on the backend and that doesn't even begin to cover it, no worrying about multiple round trips, SQL injection gone, cache invalidation solved, supports recursion, nested data
Everyone outside of Clojure/Datomic should be looking in for things to steal
The decision not to play around with the free version of proprietary software is also reasonable. Vendor lock-in is a trade off many developers are not interested in making.
[1] https://www.metalevel.at/prolog
And one from 2010: https://news.ycombinator.com/item?id=1976127
More than 200 million airline bookings, 850 million total (travel and hotel) bookings per year. They are known to run their airline reservation system on Sicstus Prolog, though I don't know how well that is publicly documented in writing.
To me, that variation is implicit within such a question.
Edit: I'm reasoning from the HN comment guidelines [0]: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."
This guideline is in fact a restatement of one of the fundamental principles of reasoned discourse, the principle of charity [1]
I have to ask- like what? Are we talking about the next javascript framework, here, or about, I don't know, modal logics or category theory?
I know a guy who got an internship at ARM during a PhD in modal logic, so, far as I can tell, modal logic is both intellectually engaging and also practical, as in useful, in practice (to be blunt: to land you a job). Is that what you are talking about?
Generally though I think it's fair to interpret any question of "why should I bother learning X" not as a statement that nothing should be learned unless there's a direct benefit, but instead as the question "what are the practical applications of X". I think most people here would agree that learning for learning's sake can be fruitful & rewarding, so there's no reason to assume otherwise in response so such a question.
Maybe they prefer to learn through building something. Maybe they're working on something and are interested to know if Prolog could help them with their project.
Edit: Found some relevant threads and links: https://news.ycombinator.com/item?id=9248107 https://www.youtube.com/watch?v=G_eYTctGZw8
Rolling back, as a declarative language in the database abstraction, the programmer can run queries with verbs that model the domain instead of SQL's generic WHERE, FROM, SELECT, etc. The price is that all facts have only three parts...like RDF [1] so maybe the programmer comes out ahead on design of the data relations.
Not all workloads are close to read-only databases. But some are, and Prolog allows writing such programs without the low level abstractions of the relational model using higher level DSL's.
[1]: https://en.wikipedia.org/wiki/Resource_Description_Framework
Prolog "facts" can have any number of arguments. The only way I can think of reconciling Prolog facts with your comment about "only three parts ... like RDF" is that Prolog facts are first-order predicates which consist of a predicate symbol, a vector of arguments and a pair of enclosing parentheses. Is that what you meant?
Paper covers Rock
Rock crushes Scissors
Scissors cut Paper
wins(paper, rock).
wins(rock, scissors).
wins(scissors, paper).
loses(X,Y) :- wins(Y,X)
A practical real-life scenario for Prolog might be a "help wizard." The next step depends on what steps we have already tried (and not tried) and other kinds of state. The next step can be expressed as a Horn Clauses.
X /\ Y /\ NOT Z -> Z
NOT B /\ NOT W /\ X /\ Z /\ A /\ Q -> M
etc.
Many time a programmer will be faced with a problem which solution is to collect a set of facts and ask arbitrary questions against those. Unless one has had some exposure with prolog, one may not recognize this problem and may start designing a custom inferior system, either from scratch or based on unfit tech.
Real life example:
I worked once for a very respectable company where we had been given the project of devising a system that would assess the trustworthiness of accesses to some sensitive application based on a ever expanding set of data collected about users, their devices, locations, and so on. We wanted the rules governing access to be defined and refined with time by the security department. So I thought that would be a good fit for some prolog-like database and looked for one; and I could actually find one that checked all the boxes: usable as a library from C++, could update the dataset and the rules without interruption, compiled the queries down to machine code to withstand our gazillions of queries-per-secs, developed indoors (to counter the NIH syndrome), and instead of FALSE the lib would also return some metadata that could be used to produce a meaningful error message.
A prototype was build in 2 weeks or so, involving 1.5 person, one of which had never used prolog before. Had never used it but knew about it. Otherwise, you can be certain that a very different path would have been taken: to hire a whole team of engineers to develop from scratch and for a very long time their very own capability system/data storage system/error reporting system that would have been less flexible and much slower, required restart for reconfiguration, etc.
You can be certain of it because that's the path the company actually decided to follow, to the great benefit of those involved, who've all been rewarded with a promotion for such an undertaking :-)
Of course some things cannot be disproven, and in those cases (again, if you don't request otherwise) you will get nontermination.
The pdf generated from his blog is also interesting :
https://github.com/hmemcpy/milewski-ctfp-pdf
These are the best resources I found about the subject.
https://github.com/JanWielemaker/swi-prolog-wasm/blob/master...
I've study a super-little-bit prolog at university time but I do not really understand it... I still have to understand "why prolog?" at all but perhaps sooner or later I'll try to review it a bit with this site-book :-)
OT, but another point to note is that the original Erlang VM and interpreter was implemented in Prolog, which (because of Joe Armstrong's affinity for the language) might be why there are so many subtle syntactical similarities between the two languages.
This tutorial does a pretty good job at first glance, but I feel like there could be some more sophisticated examples that more concretely illustrate why it's such a powerful technique to use
Constraint satisfaction to my eyes seems a bit of an obscure concept that is substantially present in any functional programming language, however since prolog is still there and popup regularly I understand that it's me that miss something and so I'm curious and perhaps sooner or later I'll try to reread docs and try to really understand while keep it a bit down in my priority list...
Here is code to append two lists in Prolog:
append([], Xs, Xs).
append([X|Xs], Ys, [X|Zs]) :-
append(Xs, Ys, Zs).
?- append([a,b], [c,d], Zs).
Zs = [a, b, c, d].
?- append(Xs, Ys, [a,b,c]).
Xs = [],Ys = [a, b, c] ;
Xs = [a],Ys = [b, c];
Xs = [a, b],Ys = [c];
Xs = [a, b, c],Ys = [].
Rust is barely influenced by functional languages.
That is arguable. Rust supports and in a lot of ways prefers functional solutions for problems, for example the iterator trait in std and a gazillion similar library APIs. Functional programming works very well with Rust's type system.
For instance, see:
Can I replace a LAMP stack with SWI-Prolog?
<table_name>(<column 1, row 1>, <column 2, row 1>, ...., <column n, row 1> )
...
<table_name>(<column 1, row m>, <column 2, row m>, ...., <column n, row m> )
Many tables exported this way will not be necessary any more, particularly those ubiquitous tables used to map other tables' keys between them ("Customer_ID_Ticket_Id" etc) and in most cases primary key fields will no longer be necessary and so on- but you can move all your data to Prolog, with very little change, is what I'm trying to say.
Mer' Christmas :)
And, since those are not usual goals of an interpreter, I would guess "not very competent" for at least the first two with high certainty.
It also raises the question of whether Postgres has a good Prolog plugin. This one looks more likely to be useful.