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

21–30 of 64 posts

Re: Prolog Basics Explained with Pokémon

#21

Post by Joker_vD »

macintux wrote: post #4

It continues to be immensely surprising to me that Joe Armstrong was able to write the initial Erlang implementation in Prolog. I wish I’d asked him about getting a copy of the source code.

    What does this say about Forth? Not much except that it isn't for me.
    Take Prolog. I know few things more insulting than having to code in
    Prolog. Whereas Armstrong developed Erlang in Prolog and liked it much
    better than reimplementing Erlang in C for speed. I can't imagine how
    this could be, but this is how it was. People are different.
from Yossi Kreinin's "My history with Forth & stack machines" [0]. Some people write APL and enjoy it. Some can't bear Lisp even after 10 years of working with it.

[0] https://yosefk.com/blog/my-history-with-forth-stack-machines...

Re: Prolog Basics Explained with Pokémon

#23

Post by Modified3019 »

satvikpendem wrote: post #19
Modified3019 wrote: post #2

Was initially nonplussed, but toward the end I realized the choice of pokemon for an example actually works out well for showing how prologue can solve problems. I’m now a bit curious about trying it out somewhere.

Nonplussed like initially surprised? It does not mean bored or nonchalant which many people seem to think, probably due to the non- prefix.

Interesting, it seems I learned/am using a modern American mutated version of the word.

https://www.broadlearners.com/t/understanding-the-meaning-of...

https://www.merriam-webster.com/grammar/whole-nother

https://old.reddit.com/r/etymology/comments/13s19j0/wtf_happ...

In my case, I was using it as almost a blend of the two meanings, something mostly meaning “unimpressed”, with a touch of “and a bit perplexed why such effort is going into this”. Basically a shoulder shrug and “okay…?”

I now find myself nonplussed, wondering if I should be using the word at all given it seems to have two opposite meanings.

Re: Prolog Basics Explained with Pokémon

#24

Post by sgarland »

Joker_vD wrote: post #20

> Then query it like so: SELECT DISTINCT pokemon, special_attack FROM pokemon as p WHERE p.special_attack > 120 AND EXISTS ( SELECT 1 FROM pokemon_moves as pm WHERE p.pokemon_name = pm.pokemon_name AND move = 'freezedry' ) AND EXISTS ( SELECT 1 FROM pokemon_types as pt WHERE p.pokemon_name = pt.pokemon_name AND type = 'ice' ); Hmm. I wonder if this SELECT DISTINCT pokemon, special_attack FROM pokemon as p NATURAL JOI…

It would, but it forces the requirement of DISTINCT. With the original, if there were declared PKs (pokemon_name is fine for the main table, with a composite for others), the semi-join (EXISTS) would eliminate the need for DISTINCT entirely.

I think. Doing this in my head, but you could verify it trivially with SQLite or any other RDBMS.

Re: Prolog Basics Explained with Pokémon

#25

Post by [deleted] »

Joker_vD wrote: post #20

> Then query it like so: SELECT DISTINCT pokemon, special_attack FROM pokemon as p WHERE p.special_attack > 120 AND EXISTS ( SELECT 1 FROM pokemon_moves as pm WHERE p.pokemon_name = pm.pokemon_name AND move = 'freezedry' ) AND EXISTS ( SELECT 1 FROM pokemon_types as pt WHERE p.pokemon_name = pt.pokemon_name AND type = 'ice' ); Hmm. I wonder if this SELECT DISTINCT pokemon, special_attack FROM pokemon as p NATURAL JOI…

[deleted]

Re: Prolog Basics Explained with Pokémon

#26

Post by triska »

macintux wrote: post #4

It continues to be immensely surprising to me that Joe Armstrong was able to write the initial Erlang implementation in Prolog. I wish I’d asked him about getting a copy of the source code.

Regarding distributed systems, I find Torbjörn Lager's recent work on Web Prolog particularly interesting. He recently posted about it here:

https://github.com/mthom/scryer-prolog/discussions/3322

and also in the course of a discussion on various approaches to implement concurrency in Prolog:

https://github.com/mthom/scryer-prolog/discussions/3307

Re: Prolog Basics Explained with Pokémon

#27

Post by Bratmon »

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 the predicates" mode, and your code will go from taking 1 second to run to taking 8 days.

And because you don't control the engine (you're not supposed to think about it, after all), there's nothing you can do but rewrite the whole thing in a traditional programming language.

Re: Prolog Basics Explained with Pokémon

#28

Post by triska »

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…

How is this different from other programming languages though?

One example I often think about is from Ken Silverman: "sub eax, 128" → "add eax, -128". So equivalent ways to write the same program may have different performance characteristics also depending on the tools that are applied. How many people could tell without trying which way to write this example is preferable?

The same phenomenon will be encountered in all kinds of languages, where engine and compiler improvements make existing code faster or slower.

Re: Prolog Basics Explained with Pokémon

#29

Post by Bratmon »

triska wrote: post #28
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…

How is this different from other programming languages though? One example I often think about is from Ken Silverman: "sub eax, 128" → "add eax, -128". So equivalent ways to write the same program may have different performance characteristics also depending on the tools that are applied. How many people could tell without trying which way to write this example is preferable? The same phenomenon will be encountered i…

In other languages, you can find the lines where the performance problems are and fix them without breaking the abstraction everywhere else.

Re: Prolog Basics Explained with Pokémon

#30

Post by triska »

Bratmon wrote: post #29
triska wrote: post #28

Earlier quoted context omitted.

How is this different from other programming languages though? One example I often think about is from Ken Silverman: "sub eax, 128" → "add eax, -128". So equivalent ways to write the same program may have different performance characteristics also depending on the tools that are applied. How many people could tell without trying which way to write this example is preferable? The same phenomenon will be encountered i…

In other languages, you can find the lines where the performance problems are and fix them without breaking the abstraction everywhere else.

I think this is very well phrased, and I would argue the same holds for Prolog too.

In my opinion, a key difference between Prolog and other languages in that regard is one of degree, not kind: Compared to other languages, addressing performance problems in Prolog engines tends to have far greater effects on Prolog programs, because so much is implicit (i.e., left to the engine).

If the performance problem is not in the engine, but in the program itself, then we will face the same questions with Prolog as with other languages: How to formulate the program better, is there a better approach altogether?

For example, earlier today an interesting question regarding performance was posted in the Scryer discussions:

https://github.com/mthom/scryer-prolog/discussions/3341

The comparison in this case is between Gecode and Scryer on a seemingly simple but nontrivial combinatorial task. What is the problem here? Most likely the Scryer engine itself can be improved. And also very likely, there are better ways to model the task, and also better search strategies, and these tend to have far greater performance impact than the base language, and these questions remain also if we change the base language.

In my opinion, these questions regarding different kinds of formulations tend to be more frequently associated with Prolog than with other languages because Prolog is more frequently used for complex tasks where it is not a priori clear how to even approach the problem.

Post reply on HN