This issue happens at the edge of every induction. These two rules support their data equally well:

data: T T T T T T F

rule1: for all i: T

rule2: for i < 7: T else F

That’s where Bayesian reasoning comes into play, where there are prior assumptions (e.g., that engineered reality is strongly biased towards simple patterns) which make one of these hypotheses much more likely than the other.

yes, if you decide one of them is much more likely without reference to the data, then it will be much more likely :)

Deciding that they are both equally likely is also a deciding a prior.

Yes, "equally likely" is the minimal information prior which makes it best suited when you have no additional information. But it's not unlikely that have some sort of context you can use to decide on a better prior.

Well that would be extra information. Wherever you find the edge of your information, you will find the "problem of induction" as presented above.

Personally I don't like the Standard ML based mash-ups.

I think Curry is an interesting take on logic programming. A sort of Haskell meets Prolog.

I can recommend "Simply Logical". I also suggest Advent of Code as a nice way to cut your teeth with expressing thoughts with Prolog.

Generally speaking, Prolog syntax is ridiculously simple and uniform. Its pattern matching is the most universal of any programming language partly because of this.

I think this article is problematic because Prolog is truly a different paradigm which requires time to understand. Laments about no strings, no functions and "x is confusing" read like expectations of a different paradigm.

Prolog is also unusual in a sense that it is essential to understand what the interpreter does with your code in order to be able to write it well. For vanilla Prolog, that's not so hard. However, when constraint programming and other extensions are added, that becomes much harder to do.

When I did my degree in Software Engineering, logic programming (with Tarsky's World), and Programming with Prolog were required classes.

There were only two prevalent attitudes, some of us really loved FP (me included), others hated it and could hardly wait to get it done.

Somehow there was a similar overlap with those of us that enjoyed going out of mainstream languages, and those that rather stay with Pascal and C.

Yeah that sounds like me too. Prolog became a fetish a few years ago. I used it intensely for 2 years, wrote a lot about it, until it became a part of me. Its intangible what it does to you, but its the dual of what you might expect.

Datalog has the same capabilities as prolog but allows strings right?

My understanding is that they have very different evaluation strategies, bottom up vs top down. But with laziness and pruning you can still achieve the same goals in datalog with more ergonomics, right?

I think every language should have a prolog or datalog implementation, kind of like regex.

In many respects "Datalog" doesn't refer to a single language or implementation or standard. It really just refers to a set of approaches for querying relational datasets using something like Prolog's unification.

By which I mean there are Datalogs that look like Prolog a bit, and others that don't. And things that are "Datalogs" that don't even have their own PL but instead more of an API. And no standard at all.

No, datalog is a decidable subset of Prolog. That changes everything.

> I think this article is problematic because Prolog is truly a different paradigm which requires time to understand.

> Prolog is also unusual in a sense that it is essential to understand what the interpreter does with your code in order to be able to write it well.

100% this!

Coming from procedural/OO paradigms i did not understand how to think about Prolog until i read Robert Kowalski's paper Predicate Logic as a Programming Language - https://www.researchgate.net/publication/221330242_Predicate...

I still have a long way to go but at least i am on the right track.

Agreed, but cuts are confusing even considering the paradigm, though. Especially considering the paradigm, actually!

They are necessary in practice, though. But boy do a cut here and there makes it harder for catching up to some Prolog codebase.

evil(x) -> not(do(x)) which equates to not(evil(x)) or not(do(x)).

The negation would be evil(x) and do(x) by DeMorgan's law.

If what you mean is all(x), evil(x) -> not(do(x))

then the negation would be exists(x), evil(x) and do(x).

Thanks for this reference; I found this paper interesting, but it is a satisfiability solver. Inherently it cannot quantify the probability of a subset of events, but it can find a probability assignment given a set of constraints. I.e. prove possibility. More usefully it can show that no such assignment is possible.

It's a typo. Its supposed to be a comma not a pipe, and read P(Q ⊆ X , ∀ x ∈ Q (x = 1)). I.e. Q is some subset of X and for all x in Q, x=1.