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

101–110 of 162 posts

Re: The Power of Prolog

#101

Post by bloak »

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. ?-…

But, but, the product of four prices cannot possible be measured in $. You must mean $^4.

Edit: Here's a solution in Haskell. I've been paid to program in both Prolog and Haskell, but it was a while ago; my knowledge of both languages is very rusty.

  main = putStrLn $ show [(a, b, c, d) | a

Re: The Power of Prolog

#102

Post by hellofunk »

tluyben2 wrote: post #18
pjmlp wrote: post #9

One of my favorite languages, pity that is has had even harder time than Lisp getting mainstream acceptance.

Picolisp has a Prolog engine built in. https://picolisp.com/wiki/?home

The important thing to remember about non-Prolog "Prolog engines" (which I think Pico's "Pilog" is), is that for large applications and data sets, generally for anything non-trivial, you need an industrial Prolog implementation for it to be fast.

Tiny Prologue-style "engines" can be fun and educational, but they are not a substitute for actual Prolog.

Re: The Power of Prolog

#103

Post by anta40 »

segmondy wrote: post #11
triska wrote: post #2

Thank you very much for the publicity, I greatly appreciate it! This book has been discussed on HN about one year ago: https://news.ycombinator.com/item?id=14045987 Since then, I have added the following new chapters: Prolog Business Cases: https://www.metalevel.at/prolog/business Sorting and Searching: https://www.metalevel.at/prolog/sorting Cryptography with Prolog: https://www.metalevel.at/prolog/cryptography Engi…

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

I studied some Prolog and Haskell in the undergraduate days. Well now my work is mostly done in Java, e.g Android.

What are strong cases to use Prolog/Haskell these days? :D

Re: The Power of Prolog

#108

Post by restalis »

I hated this language (and I'm saying it knowingly, despite the fact that this is most definitely a Prolog loving group). I found its working model difficult for me and the ROI quite low. I wanted to make my critique a bit constructive though and, before spitting out something of my own, I decided to look if there's already anything available in this regard. I think Andre Vellino puts it quite well (or at least better than I cold) in his "Prolog's Death" blogpost[1]. I invite you to have a look at it. Leaving aside Prolog's language design decisions, logical languages in general may be for now just a bit precocious, something not meant to flourish in our time. However, the computing hardware evolves and with it getting more complex and harder to predict the imperative paradigm being better fit for the underlying physical architecture becomes less and less true with every passing day. Although I can't say I'm thrilled about it, in time the logical languages may become the better offer for the average Joe looking for quick results, something closer to what for now Python is.

[1] https://synthese.wordpress.com/2010/08/21/prologs-death/

Re: The Power of Prolog

#109

Post by chriswarbo »

tabtab wrote: post #38
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 did not say "can't do". I essentially said "not as well". Of course "well" can be subjective, but if enough people don't like way a given language/tool does it, they will ignore it, like they have been with FP/logical programming for several decades. Somebody needs to articulate in careful unambiguous detail how and why it's "better" and "easier", not just repeatedly claim it. That writer apparently hasn't been bor…

You seem to be moving the goalposts to "why is FP better than X". I was simply pointing out that printf debugging is easy in FP. In fact, it's probably easier in FP, since everything is an expression, whereas imperative languages have a weird expression/statement distinction. For example, if I have code like:

    buggyCode x y = if foo x
                       then bar x y
                       else baz y
I can wrap anything on the right-hand-side in a printf (except the keywords if/then/else). At the extreme end I could do:

    buggyCode x y = trace "hit buggy code" (if trace "applying foo to x" ((trace "hit foo" foo) (trace "hit foo's x" x)
                       then trace "applying bar x to y" ((trace "applying bar to x" ((trace "hit bar" bar) (trace "hit bar's x" x))) (trace "hit bar's y" y))
                       else trace "applying baz to y" ((trace "hit baz" baz) (trace "hit baz's y" y))
I could even move the x and y arguments across to the right-hand-side using anonymous function notation, then I can trace partial applications too:

    buggyCode = trace "hit buggyCode" (\x -> trace "gave x to buggyCode" (\y -> trace "gave y to buggyCode" ))
Note that we the built-in if/then/else is mostly a legacy crutch to aid familiarity. We can just use a function instead, and printf all the things:

    ifThenElse True  x y = x
    ifThenElse False x y = y

    buggyCode = \x -> (\y -> (ifThenElse (foo x)
                                         (bar x y)
                                         (baz y)))
(Of course, defining our own if/then/else isn't much use; we're usually better off writing more meaningful, domain-specific alternatives)

Re: The Power of Prolog

#110

Post by chriswarbo »

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.

I don't know if that's the case. It can certainly be tricky to "unlearn" this instinct when trying a language like Haskell after being immersed in imperative languages, but I'm not convinced that either is 'more natural' than the other.

For example, it's easy to forget how utterly baffled a learner can be when faced with:

    x = x + 1
Post reply on HN