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

The Power of Prolog

metalevel.at

Post reply on HN
Print view View original

51–60 of 162 posts

Re: The Power of Prolog

#51

Post by tabtab »

sakuronto wrote: post #45
chriswarbo wrote: post #22

Earlier quoted context omitted.

No idea why you think functional programming can't do printf debugging. Even pure languages like Haskell have `unsafePerformIO` (or wrappers like https://hackage.haskell.org/package/base-4.11.1.0/docs/Debug... ). Also functional programming heavily encourages splitting up code into digestible chunks (they're called functions ;) )

I guess humans, being the temporal creatures we are, have an easier time debugging procedural programs because they have a "story", an expected sequence of "events" (calls, reassignments, etc.), that naturally goes with the program. Functional programming inherently obscures that.

"Frogs might like go-to's": Joke from a heated debate about "go to" statements regarding whether go-to's are objectively bad, or it's matter of something in the human mind.

Re: The Power of Prolog

#52

Post by YeGoblynQueenne »

tom_mellior wrote: post #15
tabtab wrote: post #12

Earlier quoted context omitted.

Let's face it, procedural is just plain easier to debug because you can more easily split it into digestible and dissect-able chunks: divide-and-conquer. Perhaps functional and logical CAN readily have such features, but nobody either figured how, or have not figured out how to explain how to do dissection to normal people. (This is sometimes a criticism of SQL also, but the added WITH clause helps break up big queri…

Prolog has print statements you can stick anywhere. (It also has proper debuggers that allow you to go forward and backward and all that.) Also, Prolog code is often "split into digestible chunks". Even more than other languages, in fact, because it's rather hard to write nested loops or nested predicates or nested many other things. If you were ever taught Prolog, it seems that you weren't taught well. You might wan…

>> Also, Prolog code is often "split into digestible chunks". Even more than other languages, in fact, because it's rather hard to write nested loops or nested predicates or nested many other things.

I find it very easy to write nested loops in Prolog:

  findall(A
         ,findall(B
                  ,findall(D
                          ,findall(...)
                           ,G)
                  ,E)
          ,C)
To paraphrase the old saying, a good Python programmer can write Python in any language.

Re: The Power of Prolog

#53

Post by YeGoblynQueenne »

sakuronto wrote: post #45
chriswarbo wrote: post #22

Earlier quoted context omitted.

No idea why you think functional programming can't do printf debugging. Even pure languages like Haskell have `unsafePerformIO` (or wrappers like https://hackage.haskell.org/package/base-4.11.1.0/docs/Debug... ). Also functional programming heavily encourages splitting up code into digestible chunks (they're called functions ;) )

I guess humans, being the temporal creatures we are, have an easier time debugging procedural programs because they have a "story", an expected sequence of "events" (calls, reassignments, etc.), that naturally goes with the program. Functional programming inherently obscures that.

Prolog on the other hand has a very clear imperative reading, that fits alongside the declarative one. In fact, this is probably one reason why many programmers used to imperative languages find it hard to pick up Prolog and run with it - they get distracted by the imperative reading.

On the other hand, that makes it much easier to debug code, by thinking along the lines of "p/2 is called after p/4" or even "p/2 returns A that is passed to p/4" (even though strictly speaking predicates don't "return" stuff).

Re: The Power of Prolog

#54

Post by kccqzy »

triska wrote: post #49
kccqzy wrote: post #47

One of the coolest things I've seen is to use Prolog with CLP(FD) to solve the 7-11 problem. The problem basically says the sum of the prices of four items is $7.11, and the product is $7.11 too (no rounding); find the prices of these four items. This can be solved in two lines of code that gives the (unique) solution in a second. Not even my expensive Mathematica can do this! ?- use_module(library(clpfd)). true. ?-…

Hah! I used exactly this example to motivate the arbitrary precision CLP(FD) implementation, published as The Finite Domain Constraint Solver of SWI-Prolog , FLOPS 2012, LNCS 7294: https://www.metalevel.at/swiclpfd.pdf The observations on type inference are also spot on. The project you mentioned was previously discussed on HN, but the page is no longer available: https://news.ycombinator.com/item?id=12108041

Oh you implemented this CLP(FD) and wrote that paper! Thanks a lot! My 7-11 example is probably because I first saw it in your paper then.

Re: The Power of Prolog

#55

Post by FractalLP »

lispm wrote: post #23
segmondy wrote: post #11

Earlier quoted context omitted.

I've shared this with anyone who will let me divert the conversation to Prolog. At work we have the Haskell folks, the Lispers who move everything towards Lisp, and I'm the one who moves every conversion towards Prolog, then I send the link to this. :-D

The older Lisp folks often have a Prolog integrated in their system...

Mini-kanren?

Re: The Power of Prolog

#57

Post by YeGoblynQueenne »

triska wrote: post #42
Koshkin wrote: post #40

Earlier quoted context omitted.

> easier to debug Incidentally, my impression has been that the use of a declarative (or pure functional) language leads to spending drastically less (if any at all) time debugging. If your code makes sense (to you), it will work. Or, as an old adage goes, "If it compiles, it works."

I can confirm this impression. In my opinion, there are several reasons for this: First, many types of mistakes that are common when working with lower-level languages cannot occur at all when you use a declarative language. For example, with a logic programming language, you cannot accidentally double-free a pointer or write into unintended portions of memory. Second, when working with a high-level language, the cod…

You guys must come from another planet, because I spend 90% of my time coding in Prolog debugging my code. My code sure makes sense to me- but the interpreter frequently disagrees.

Additionally, there are some constructs that are pretty damn hard to debug. For example- deeply-nested recursive loops with multiple clauses and free backtracking; you never know which clause you're in or how deep in the recursion. Well- you do but it demands a great deal of concentration.

Or take my personal tracing nightmare- DCGs. At some point, you inevitably end up with something like this:

_24234 = _12734

Then you have to squint up the trace to find the two variables to figure out what's going on.

Re: The Power of Prolog

#58

Post by ysleepy »

triska wrote: post #49
kccqzy wrote: post #47

One of the coolest things I've seen is to use Prolog with CLP(FD) to solve the 7-11 problem. The problem basically says the sum of the prices of four items is $7.11, and the product is $7.11 too (no rounding); find the prices of these four items. This can be solved in two lines of code that gives the (unique) solution in a second. Not even my expensive Mathematica can do this! ?- use_module(library(clpfd)). true. ?-…

Hah! I used exactly this example to motivate the arbitrary precision CLP(FD) implementation, published as The Finite Domain Constraint Solver of SWI-Prolog , FLOPS 2012, LNCS 7294: https://www.metalevel.at/swiclpfd.pdf The observations on type inference are also spot on. The project you mentioned was previously discussed on HN, but the page is no longer available: https://news.ycombinator.com/item?id=12108041

This reminds me of a recent HN post about a simple datalog engine being used in the rust borrow checker.

https://github.com/frankmcsherry/blog/blob/master/posts/2018...

via

https://news.ycombinator.com/item?id=17107527

Re: The Power of Prolog

#59

Post by Risord »

chriswarbo wrote: post #22
tabtab wrote: post #12

Earlier quoted context omitted.

Let's face it, procedural is just plain easier to debug because you can more easily split it into digestible and dissect-able chunks: divide-and-conquer. Perhaps functional and logical CAN readily have such features, but nobody either figured how, or have not figured out how to explain how to do dissection to normal people. (This is sometimes a criticism of SQL also, but the added WITH clause helps break up big queri…

No idea why you think functional programming can't do printf debugging. Even pure languages like Haskell have `unsafePerformIO` (or wrappers like https://hackage.haskell.org/package/base-4.11.1.0/docs/Debug... ). Also functional programming heavily encourages splitting up code into digestible chunks (they're called functions ;) )

I don’t have Haskell experince but I could imagine that traditional debug experience is a bit different if you have lot of functions as values. It’s at least more challenging to visualize function which is composed from 4 another ones and have maybe partially aplied parameters VS map of strings. Or how this goes?

Ps: I currently prefer my .NET as F# and so on but debuggability doesn’t feel biggest strength indeed altough it’s usually ok.

Re: The Power of Prolog

#60

Post by madhadron »

lispm wrote: post #23
segmondy wrote: post #11

Earlier quoted context omitted.

I've shared this with anyone who will let me divert the conversation to Prolog. At work we have the Haskell folks, the Lispers who move everything towards Lisp, and I'm the one who moves every conversion towards Prolog, then I send the link to this. :-D

The older Lisp folks often have a Prolog integrated in their system...

Actual Prolog. Allegro ships a fully integrated Prolog as part of their product.
Post reply on HN