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

Learn Prolog Now (2006)

lpn.swi-prolog.org

Post reply on HN
Print view View original

161–170 of 251 posts

Re: Learn Prolog Now (2006)

#161

Post by Jtsummers »

hunterpayne wrote: post #159
Jtsummers wrote: post #140

Earlier quoted context omitted.

I don't know about MongoDB and its query language, but wrt Fortran, it's unreasonable to say that Prolog is more powerful than Fortran (or vice versa). A more reasonable statement is that Prolog is more expressive than Fortran (though this gets fuzzy, we have to define expressiveness in a way that lets us rank languages). But the power of a language normally means what we can compute using that language. Prolog and F…

I would say most programs are easier in Fortran. But there are things you can't express in Fortran but you can in Prolog. There is nothing like the cut operator in Fortran for example. They are very different animals.

You seem to be confusing two different things: What is easily or natively expressed in the language, and what can be expressed in the language.

You can create a logical equivalent of the cut operator in Fortran if you wanted to, but there's no native mechanism or operator to rely on. The languages possess the same computing "power", the difference is not in what they can compute which is your claim with "there are things you can't express in Fortran but you can in Prolog" (utter nonsense). Anything you can get a Prolog program to do, you can get a Fortran program to do (and vice versa).

Re: Learn Prolog Now (2006)

#162

Post by scotty79 »

hunterpayne wrote: post #154
scotty79 wrote: post #112

Earlier quoted context omitted.

It's a query language for graph database. You can write A* and N-Queens in SQL, but why?

Performance, far better performance. Same reason you ever use SQL. Prolog can do the same thing for very specific problems. PS Prolog is a Horn clause solver. You characterizing it as a query language for a graph database, well it doesn't put you in the best light. It makes it seem like you don't understand important foundational CS math concepts.

I have no idea why are you dissing query languages. Software that makes those work is immensely complex and draws on a ton of CS math concepts and practical insights. But maybe you don't understand that.

I'm using SQL to do SQL things. And I'm sure when I somehow encounter the 1% of problems that prolog is the right fit for I'd be delighted to use it. However doing general algorithms in Prolog is as misguided as in SQL.

Re: Learn Prolog Now (2006)

#163

Post by hunterpayne »

scotty79 wrote: post #162
hunterpayne wrote: post #154

Earlier quoted context omitted.

Performance, far better performance. Same reason you ever use SQL. Prolog can do the same thing for very specific problems. PS Prolog is a Horn clause solver. You characterizing it as a query language for a graph database, well it doesn't put you in the best light. It makes it seem like you don't understand important foundational CS math concepts.

I have no idea why are you dissing query languages. Software that makes those work is immensely complex and draws on a ton of CS math concepts and practical insights. But maybe you don't understand that. I'm using SQL to do SQL things. And I'm sure when I somehow encounter the 1% of problems that prolog is the right fit for I'd be delighted to use it. However doing general algorithms in Prolog is as misguided as in S…

> I have no idea why are you dissing query languages.

I'm not. I'm pointing out that saying a Horn clause interpreter is a graph query language indicates a fundamental misunderstanding on your part. Prolog handles anything you want to say in formal logic very well (at the cost of not doing anything else well).

SQL on the other handle uses a completely different mathematical framework (relational algebra and set theory). This allows really effective optimization and query planning on top of a DB kernel.

A graph DB query language on the other hand should be based upon graph theory. Which is another completely different mathematical model. I haven't been impressed by the work in this area. I find these languages are too often dialects of SQL instead of a completely different thing based upon the correct mathematical model.

PS I used to write DBs. Discretion is the better part of valor here.

Re: Learn Prolog Now (2006)

#164

Post by hunterpayne »

Jtsummers wrote: post #161
hunterpayne wrote: post #159

Earlier quoted context omitted.

I would say most programs are easier in Fortran. But there are things you can't express in Fortran but you can in Prolog. There is nothing like the cut operator in Fortran for example. They are very different animals.

You seem to be confusing two different things: What is easily or natively expressed in the language, and what can be expressed in the language. You can create a logical equivalent of the cut operator in Fortran if you wanted to, but there's no native mechanism or operator to rely on. The languages possess the same computing "power", the difference is not in what they can compute which is your claim with "there are th…

> You can create a logical equivalent of the cut operator in Fortran if you wanted to

In isolation, no you can't. You could implement a Prolog interpreter in Fortran however. And if you did that, you would be able to write a cut operator because then you are interacting directly with Prolog's machinery. Part of the definition of the cut operator involves changing how code around it behaves. You can't do this with Fortran (or other languages) normally. Then there is the entire concept of backtracking with isn't native in any other language (that I know of).

You could probably make a very poor cut operator in a language with an Any/Object type and casting but why would you. You are not wrong about the math. But you are ignoring the absurd amount of code you would have to write to do it. Its a bit hand-wavy to say because you can implement Prolog in a language, its just as powerful. Although that is mathematically correct but in practice it really isn't.

Re: Learn Prolog Now (2006)

#165

Post by hunterpayne »

jodrellblank wrote: post #158
hunterpayne wrote: post #128

Earlier quoted context omitted.

Its a Horn clause resolver...that's exactly the kind of reasoning that LLMs are bad at. I have no idea how to graft Prolog to an LLM but if you can graft any programming language to it, you can graft Prolog more easily. Also, that you push Python and JavaScript makes me think you don't know many languages. Those are terrible languages to try to graft to anything. Just because you only know those 2 languages doesn't m…

> Also, that you push Python and JavaScript I didn't push them. > Those are terrible languages to try to graft to anything. Web browsers, Blender, LibreOffice and Excel all use those languages for embedded scripting. They're fine. > Just because you only know those 2 languages doesn't make them good choices for something like this. You misunderstood my claim and are refuting something different. I said there is more…

I'm not. Python and JS are scripting languages. And in this case, we want something that models formal logic. We are hammering in a nail, you picked up a screwdriver and I am telling you to use a claw hammer.

Re: Learn Prolog Now (2006)

#166

Post by YeGoblynQueenne »

jodrellblank wrote: post #54
disambiguation wrote: post #40

I am once again shilling the idea that someone should find a way to glue Prolog and LLMs together for better reasoning agents. https://news.ycombinator.com/context?id=43948657 Thesis: 1. LLMs are bad at counting the number of r's in strawberry. 2. LLMs are good at writing code that counts letters in a string. 3. LLMs are bad at solving reasoning problems. 4. Prolog is good at solving reasoning problems. 5. ??? 6. LLM…

> "4. Prolog is good at solving reasoning problems." Plain Prolog's way of solving reasoning problems is effectively: for person in [martha, brian, sarah, tyrone]: if timmy.parent == person: print "solved!" You hard code some options, write a logical condition with placeholders, and Prolog brute-forces every option in every placeholder. It doesn't do reasoning . Arguably it lets a human express reasoning problems bet…

>> You hard code some options, write a logical condition with placeholders, and Prolog brute-forces every option in every placeholder. It doesn't do reasoning.

SLD-Resolution with unification (Prolog's automated theorem proving algorithm) is the polar opposite of brute force: as the proof proceeds, the cardinality of the set of possible answers [1] decreases monotonically. Unification itself is nothing but a dirty hack to avoid having to ground the Herbrand base of a predicate before completing a proof; which is basically going from an NP-complete problem to a linear-time one (on average).

Besides which I find it very difficult to see how a language with an automated theorem prover for an interpreter "doesn't do reasoning". If automated theorem proving is not reasoning, what is?

___________________

[1] More precisely, the resolution closure.

Re: Learn Prolog Now (2006)

#168

Post by YeGoblynQueenne »

bobbylarrybobby wrote: post #78
disambiguation wrote: post #40

I am once again shilling the idea that someone should find a way to glue Prolog and LLMs together for better reasoning agents. https://news.ycombinator.com/context?id=43948657 Thesis: 1. LLMs are bad at counting the number of r's in strawberry. 2. LLMs are good at writing code that counts letters in a string. 3. LLMs are bad at solving reasoning problems. 4. Prolog is good at solving reasoning problems. 5. ??? 6. LLM…

IIRC IBM’s Watson (the one that played Jeopardy) used primitive NLP (imagine!) to form a tree of factual relations and then passed this tree to construct Prolog queries that would produce an answer to a question. One could imagine that by swapping out the NLP part with an LLM, the model would have 1. a more thorough factual basis against which to write Prolog queries and 2. a better understanding of the queries it sh…

Not so "primitive" NLP. Watson started with what its team called a "shallow parse" of a sentence using a dependency grammar and then matched the parse to an ontology consisting of good, old fashioned frames [1]. That's not as "advanced" as an LLM but far more reliable.

I believe the ontology was indeed implemented in Prolog but I forget the architecture details.

______________

[1] https://en.wikipedia.org/wiki/Frame_(artificial_intelligence...

Re: Learn Prolog Now (2006)

#169

Post by zelphirkalt »

jm4 wrote: post #75
hacker_homie wrote: post #59

Earlier quoted context omitted.

Prolog doesn't look like javascript or python so: 1. web devs are scared of it. 2. not enough training data? I do remember having to wrestle to get prolog to do what I wanted but I haven't written any in ~10 years.

It's been a while since I have done web dev, but web devs back then were certainly not scared of any language. Web devs are like the ultimate polyglots. Or at least they were. I was regularly bouncing around between a half dozen languages when I was doing pro web dev. It was web devs who popularized numerous different languages to begin with simply because delivering apps through a browser allowed us a wide variety o…

Maybe they were, but these days everything must be in JS syntax. Even if it is longer than pure CSS, they want the CSS inside JS syntax. They are only ultimate polyglot as long as all the languages are actually JS.

(Of course this is an overgeneralization, since obviously, there are web developers, who do still remember how to do things in HTML, CSS and, of course JS.)

Post reply on HN