Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prolog Basics Explained with Pokémon

unplannedobsolescence.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Prolog Basics Explained with Pokémon

#31

Post by repelsteeltje »

Bratmon wrote: post #27
jodrellblank wrote: post #17

> " Don't be bothered with by the fact that the solutions end with "or false" here. It's a function of how the search algorithms work; the solver looked for more solutions, then failed. I'll admit, I don't totally understand why it only sometimes does this, but it's expected. " I think this is explained in The Power of Prolog[1] that the answers coming from Prolog are not printing text to a terminal, they are valid P…

This embodies why I don't like Prolog. Prolog's philosophy is that you should just write the predicates without thinking about how the engine works. But as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results, and shortly after that you'll find yourself in the "exhaustively try every possible combination until we get one that satisfies t…

I somewhat disagree that you shouldn't be aware of how the engine works. The mechanics are quite simple. Prolog's horn clauses are combined in depth first search manner trying to proof that the negated goal is false.

However, most prolog books focus on rooting the declarative mindset because programmers are generally more familiar with imperative programming. But just as with SQL or lisp there are definitely good ways, bad ways and plain mistakes you can make when approaching a problem.

Re: Prolog Basics Explained with Pokémon

#32

Post by lll-o-lll »

Bratmon wrote: post #27
jodrellblank wrote: post #17

> " Don't be bothered with by the fact that the solutions end with "or false" here. It's a function of how the search algorithms work; the solver looked for more solutions, then failed. I'll admit, I don't totally understand why it only sometimes does this, but it's expected. " I think this is explained in The Power of Prolog[1] that the answers coming from Prolog are not printing text to a terminal, they are valid P…

This embodies why I don't like Prolog. Prolog's philosophy is that you should just write the predicates without thinking about how the engine works. But as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results, and shortly after that you'll find yourself in the "exhaustively try every possible combination until we get one that satisfies t…

> as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results

The same is true of SQL query planners. You can perform basic queries without understanding how your SQL engine of choice works under the hood, but if you want performance, you must understand how your DB works. SQL is just the interface.

This is different in kind from imperative programming languages (which are much closer in abstraction to the underlying machine architecture), but we rub along with SQL ok; why not Prolog?

Re: Prolog Basics Explained with Pokémon

#33

Post by alexpetros »

admeliora01 wrote: post #15

Love this use case, makes me want to implement something similar for Magic the Gathering. I love using scryfall, but I think a more cli first approach with descriptive rules would suffice much better for brewing in eternal formats like Commander with ever growing card pools. I mostly work off of keyword search.

I'm not as familiar with Magic, but I've always been curious if that community has tooling at a comparable level of maturity to Pokemon Showdown.

Re: Prolog Basics Explained with Pokémon

#35

Post by Dylan16807 »

AlotOfReading wrote: post #13
ModernMech wrote: post #7

Earlier quoted context omitted.

Importantly, Datalog is not Turing-complete though.

You can get Turing completeness by wrapping your datalog query in a while loop, so that's not particularly restrictive.

You can get Turing completeness by wrapping basically any math or logic system in a while loop, even arithmetic. So that doesn't tell us much about the restrictiveness of the overall system since I'd call "you can only use arithmetic" pretty damn restrictive.

Re: Prolog Basics Explained with Pokémon

#36

Post by AdieuToLogic »

Bratmon wrote: post #27
jodrellblank wrote: post #17

> " Don't be bothered with by the fact that the solutions end with "or false" here. It's a function of how the search algorithms work; the solver looked for more solutions, then failed. I'll admit, I don't totally understand why it only sometimes does this, but it's expected. " I think this is explained in The Power of Prolog[1] that the answers coming from Prolog are not printing text to a terminal, they are valid P…

This embodies why I don't like Prolog. Prolog's philosophy is that you should just write the predicates without thinking about how the engine works. But as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results, and shortly after that you'll find yourself in the "exhaustively try every possible combination until we get one that satisfies t…

> Prolog's philosophy is that you should just write the predicates without thinking about how the engine works.

This is the definition of declarative programming[0].

0 - https://en.wikipedia.org/wiki/Declarative_programming

Re: Prolog Basics Explained with Pokémon

#38

Post by Bratmon »

lll-o-lll wrote: post #32
Bratmon wrote: post #27

Earlier quoted context omitted.

This embodies why I don't like Prolog. Prolog's philosophy is that you should just write the predicates without thinking about how the engine works. But as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results, and shortly after that you'll find yourself in the "exhaustively try every possible combination until we get one that satisfies t…

> as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results The same is true of SQL query planners. You can perform basic queries without understanding how your SQL engine of choice works under the hood, but if you want performance, you must understand how your DB works. SQL is just the interface. This is different in kind from imperative…

Yeah, but the difference is that SQL provides a huge number of ways to solve the "My query got slow when it got complicated" problem. In Prolog, you have the cut operator, and when that stops working for your usecase, you're just SOL.

Re: Prolog Basics Explained with Pokémon

#40

Post by zzo38computer »

fl1pper wrote: post #22

I'm not familiar with Pokemon universe :( Can somebody please explain Pokemon using Prolog?

There is a lot more than only what they explain in that article (I don't know of any full implementation of Pokemon in Prolog, although there is an implementation in TypeScript).

For example, you can also switch out (to activate a different pokemon) instead of attacking (switching has priority over attacking, so if you switch out then the opponent's attack will hit your newly active pokemon).

There are also many calculations involved, and it can be helpful to know how most of them work.

Post reply on HN