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

131–140 of 162 posts

Re: The Power of Prolog

#131

Post by pjmlp »

anentropic wrote: post #123
triska wrote: post #17

Earlier quoted context omitted.

I once asked my Prolog instructor why this all takes so long. His reply: "How well are you prepared for the next ISO meeting?" At that point, I realized that if you prepare yourself in earnest for, say, the standardization process, or even to accomplish any concrete improvement in Prolog systems (such as better indexing, more advanced constraints, faster garbage collection etc.), then there is so much to do that ther…

it sounds like ISO standardisation was a mistake?

When I was at the university, the ISO was freshly baked, what mattered was SWI and SICStus compatibility.

Pascal's issues regarding industrial use and poliferation of dialects were mostly fixed with ISO Extended Pascal, other than GNU, everyone else ignored it and focused on Turbo Pascal/Object Pascal compatibility instead.

Ruby and Eiffel happen to have ISO standards, but I bet even developers on those communities don't know it.

For a long time whatever ISO SQL was had not so much to do with what RDMS were actually providing.

ISO only matters if it is something vendors actually care about.

Re: The Power of Prolog

#132

Post by triska »

jacquesm wrote: post #74
triska wrote: post #19

Earlier quoted context omitted.

Thank you for sharing this, I really appreciate you participating in this thread and this awesome anecdote! One related workplace anecdote that a former fellow student told me: He was working on a rule-based medical recommender system, and he recognized that Prolog was an excellent fit for this project. When he first suggested that the team switch to Prolog, they were very skeptical. But someone high up in the chain…

> My colleague told me that, a few months after that, the whole team regarded Prolog as the only viable solution to all further projects from then on! Hm, there is such a thing as the right tool for the job. If all their jobs were very similar that makes sense, otherwise, not so much. Are you aware of the fact that inside every Windows NT installation there was a Prolog engine to help with network configuration? http…

Personally, I found this the fun aspect of this story: that what one regards as "the" (as opposed to a) right tool for the job can change so quickly, and can so strongly depend on one's perspective!

Thank you for the link to the Prolog-based network configuration!

Re: The Power of Prolog

#134

Post by dontwantai »

I imagine that there must be some system similar to prolog but with a probabilistic model of inference, for example ground rules could be sorted by statistical properties to accelerate inference. Just like machine learning trees select features for classification (perhaps using cross-entropy minimization).

Edit: I found Journal of Machine Learning Research 7 (2006) 307–342, Kernels on Prolog Proof Trees: Statistical Learning in the ILP Setting

Re: The Power of Prolog

#135

Post by tabtab »

the_af wrote: post #69
tabtab wrote: post #38

Earlier quoted context omitted.

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…

At least some of your assumptions are wrong: no-one is ignoring FP anymore.

They don't have a choice: the latest languages force it on you by not giving better alternatives. For example, their stiff object models. For instance, why the heck can't one easily attach an on-click method to a Java button, instead forced to use silly lambdas? It would be more natural and simpler. Over-focus on FP damaged the OOP improvements/designs. Each generation seems to over-do something, and then the pendulum swings the other way.

Re: The Power of Prolog

#136

Post by tabtab »

simion314 wrote: post #118
tabtab wrote: post #41

Earlier quoted context omitted.

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 d…

Prolog is ideal for some kind of problems, good programmers should know what logic programming is and what problems are perfect for logic programming, then if in real life you hit such a problem you can chose prolog or a library that does logic programming.

I'd like to see a comparison to the alternatives to illustrate objective benefits. I've been down that road before in my-language-can-beat-up-your-language debates, and the end result is usually, "Well, my approach looks easier and simpler TO ME; you just think wrong." Other times they do queries in the app language when they should be using a database.

Re: The Power of Prolog

#137

Post by tabtab »

tabtab wrote: post #35
simion314 wrote: post #33

Earlier quoted context omitted.

Your Console.log will not help you in a recursive function

If you have the right tracking variables, it's great for the job: "console.write(currentNodeID, parentNodeID, depthLevel, nodeVisitCount);" And one can wrap that into a conditional if they don't want to echo the entire journey. It's usually good to create such tracking variables in non-trivial systems anyhow. Bleep happens.

Correction: should be "nodesVisitedCount". Also note that output formatting was sacrificed for brevity of the example.

Re: The Power of Prolog

#138

Post by collyw »

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

With mixed model programming (Python) I usually find it the most difficult part of the program to debug when functions are being passed around. SQL on the other hand either works or it doesn't. ( don't know Prolog but it does look interesting).

Re: The Power of Prolog

#139

Post by carapace »

lucb1e wrote: post #99
carapace wrote: post #91

Earlier quoted context omitted.

Ooo! Lemme show off this CLP(FD) solution to the "Zebra Puzzle" https://en.wikipedia.org/wiki/Zebra_Puzzle that I made after reading the "Logic Puzzles with Prolog" chapter: https://gist.github.com/calroc/603ed919bc814ccee10c1b3df6142...

That makes Prolog look downright useful! I heard from lots of people that it's fun as an esoteric language and some had a homework assignment or two in it, but nobody really uses it in practice. Do you think this might be more useful as a module to solve logic puzzles, rather than as a complete language by itself? I learned the very basics, but not worked with it enough myself to say whether that would be better than…

Well, the idea that "nobody really uses it in practice" doesn't hold up to the evidence in this thread, eh? It's used and under active development. I think it lacks hype. :-)

> Do you think this might be more useful as a module to solve logic puzzles, rather than as a complete language by itself?

I was thinking about it this morning and I came to the conclusion that Prolog really is AI. They did it. We have AI already and most of us just failed to notice. The Unification algorithm at the heart of Prolog (I'm not an expert!) is pretty much what your brain does when you solve logical puzzles and problems. We have a machine that can think.

The way I think of Prolog is as a super-calculator that can be applied to a huge range of problems and tasks. (One thing to be aware of is that if you have a Prolog-shaped problem and try to solve it in some other language you'll likely wind up reinventing some portion of Prolog in that language! If you look up solutions to the Zebra Puzzle written in other languages you'll see that most of them proceed by implementing some sort of logic solver that resembles a crude Prolog.) There may be practical real-world issues in performance or interfacing for a given application, but in general I'd say that good ol' Prolog is vastly underutilized. (Put another way, we're working harder than we should be.)

Re: The Power of Prolog

#140

Post by pyrale »

Risord wrote: post #59
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 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 alt…

Although debugging in haskell typically feels different than procedural or OO languages (much less state to rely on, so debugging is used much less to understand what happens, and much more to control that your next logical step checks out), grandparent's assertion that you can't printf simply lacks merit.
Post reply on HN