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

41–50 of 162 posts

Re: The Power of Prolog

#41

Post by tabtab »

simion314 wrote: post #36
dozzie wrote: post #27

Earlier quoted context omitted.

> printing things to the console is the poor man debugger. You may want to try working with network before making this statement, when you cannot step through a function because of timeouts. Or maybe even looking at tracing debuggers, like strace, ltrace, or Erlang's gdb, which all do little more than "printing things to the console". Logging (and logging-like tools) is a very important way of debugging services, you…

Sure, if you do not have the debugger you use the logging, but you will miss the main features of a debugger like see the entire call stack, all the variables and parameters at each call stack level, you can evaluate expressions in that context. I use logging to log problems that would happen on a user machine or server where I can't open the debugger and see it. When an error happens on a server or a customer machin…

Each do better under certain situations. One is a hammer and another a tweezer. Different debugging jobs/steps need different tools. But the real question is whether the hammer/tweezer kit that comes with Prolog is better than the hammer/tweezer kit of other paradigms/languages.

In my personal opinion and observation, the hierarchical step-wise refinement approach is quicker for most developers to grasp, learn, and debug. Maybe if those of us who don't see the grokkability benefits try it for 50 years, it will finally click. But you better hope to be in management by then because the programming field doesn't like "old people". I'm just the messenger.

Re: The Power of Prolog

#42

Post by triska »

Koshkin wrote: post #40
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…

> 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 code is much shorter than if you had used a lower-level language. This makes it easier to debug, and also easier to get right already in the first few tries.

Third, once there is a mistake, it can be found in ways that fit the overall paradigm nicely. For example, in pure Prolog, if your predicate terminates and has a mistake, then it is either too specific or too general (or both), and you can debug both cases very systematically and even automatically, using built-in mechanisms of the language.

Declarative debugging methods for Prolog were pioneered by Ehud Shapiro in his 1982 PhD thesis, Algorithmic Program Debugging:

https://cpsc.yale.edu/sites/default/files/files/tr237.pdf

I also highly recommend Ulrich Neumerkel's teleteaching environment GUPU for systematically finding mistakes in Prolog programs:

https://www.complang.tuwien.ac.at/ulrich/gupu/

Re: The Power of Prolog

#43

Post by triska »

Immortalin wrote: post #30
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…

A section on dynamic programming w.r.t. to modern AI techniques would complement it nicely considering the resurgence of the field :D

Thank you, this sounds like a wonderful addition!

In general, the AI chapter is what I am currently working on most. I mean not "only" on the actual content, but on the applications I want to present in this chapter.

Anton Kochkov has recently motivated this chapter via a dedicated issue for AI/ML applications of Prolog, and I invite you to track its progress at:

https://github.com/triska/the-power-of-prolog/issues/5

Re: The Power of Prolog

#44

Post by triska »

tom_mellior wrote: post #25
tabtab wrote: post #20

Earlier quoted context omitted.

A big problem with visual debuggers is that they are too blunt of an instrument. Often I wish to examine specific things under specific conditions and thus use conditionals to narrow down what's being explored instead of bajillion breakpoints and/or log records. Debuggers could add conditional expressions, but then they'd be re-inventing WRITE statements anyhow. As far as the nearby statement that maybe I didn't lear…

> Debuggers could add conditional expressions, but then they'd be re-inventing WRITE statements anyhow. SWI-Prolog's debugger can be invoked conditionally whenever you want from inside your running application. I've used it many times, and the code is simply: (Condition -> gtrace ; true) It's true that you could stick a write there, but you would have to think about what pieces of data you will need. Your mileage may…

Regarding your last sentence: Yes, I can confirm that this has happened, to a reasonable extent of "learned" in the sense that people went on to write programs using this material. However, I do not know how common this is, since I almost exclusively get feedback from those who found the material suitable. There were definitely complete beginners among them. For instance, here is a discussion that happened a few months ago, where it appears that also beginners comment positively:

https://www.reddit.com/r/programming/comments/7pbkfv/great_f...

More recently, two university instructors started to use this book in courses that assume no previous knowledge about the language:

Andrej Bauer in his specialist elective course Principles of Programming Languages at the University of Ljubljana:

https://ucilnica.fri.uni-lj.si/course/view.php?id=67

Norbert Zeh in his Principles of Programming Languages lectures at Dalhousie University in Canada:

https://web.cs.dal.ca/~nzeh/Teaching/3136/index.html

Much of my current work is aimed towards making the teleteaching environment GUPU available in a free Prolog system:

https://www.complang.tuwien.ac.at/ulrich/gupu/

This will help a lot to teach Prolog to beginners in a scalable way.

On a rather personal, and maybe controversial, note: I regard the self-taught Prolog master as prevalent as for example the self-taught piano, chess or Zen master. In my experience, learning Prolog properly requires dedicated guidance, and it would be highly unusual to achieve mastery without it.

Re: The Power of Prolog

#45

Post by sakuronto »

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

Re: The Power of Prolog

#46

Post by YeGoblynQueenne »

triska wrote: post #43
Immortalin wrote: post #30

Earlier quoted context omitted.

A section on dynamic programming w.r.t. to modern AI techniques would complement it nicely considering the resurgence of the field :D

Thank you, this sounds like a wonderful addition! In general, the AI chapter is what I am currently working on most. I mean not "only" on the actual content, but on the applications I want to present in this chapter. Anton Kochkov has recently motivated this chapter via a dedicated issue for AI/ML applications of Prolog, and I invite you to track its progress at: https://github.com/triska/the-power-of-prolog/issues/5

Hi Markus, thanks for your hard work on this website (also on all the Swi constraint libraries).

For your machine learning section, you might want to consider discussing Metagol [1], a modern ILP system that can learn recursive theories and perform predicate invention.

The core Metagol implementation is tiny and relies on a meta-interpreter (the technique is called Meta-Interpretive Learning). It is a radically different approach to previous ILP systems but much simpler and easier to understand. It should be interesting to anyone who wants to do machine learning with Prolog.

____________

[1] https://github.com/metagol/metagol

Re: The Power of Prolog

#47

Post by kccqzy »

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.
    
    ?- Vs = [A,B,C,D], Vs ins 1..711, A * B * C * D #= 711000000, A + B + C + D #= 711, A #>= B, B #>= C, C #>= D, labeling([ff, down], Vs).
    Vs = [316, 150, 125, 120],
    A = 316,
    B = 150,
    C = 125,
    D = 120 ;
    false.
Another great thing Prolog is good at is type inference. After all, type inference, in its simplest form, is just syntax-directed constraint generation and then using unification to solve constraints—exactly what Prolog gives you by default. You can write a type inference engine for simply typed lambda calculus in Prolog in 10 minutes. Google used to have a project to do type inference for Python written in Prolog, although they've since [switched away](https://github.com/google/pytype).

Re: The Power of Prolog

#49

Post by triska »

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

Re: The Power of Prolog

#50

Post by YeGoblynQueenne »

tabtab wrote: post #12
pjmlp wrote: post #9

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

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…

Do you know about the four-port Prolog debugger, a.k.a. the Prolog tracer? If not, it's used to actually step through your code, one call at a time. You can set breakpoints and everything. Swi-Prolog even has a graphical interface for it (though I personally prefer the textual interface).

Bottom line- yes, you can add print statements etc, but you can also directly debug your Prolog code just like you'd do for an imperative language.

Post reply on HN