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

151–160 of 162 posts

Re: The Power of Prolog

#151

Post by flavio81 »

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

Prolog-ers and Lispers are friends ebony and ivory / live together in perfect harmony

etc

Re: The Power of Prolog

#153

Post by flavio81 »

hellofunk wrote: post #102
tluyben2 wrote: post #18

Earlier quoted context omitted.

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.

Im taking note.

Question, is there any industrial strength Prolog for Commom Lisp, besides the Allegro product?

Re: The Power of Prolog

#154

Post by simion314 »

tabtab wrote: post #149
simion314 wrote: post #142

Earlier quoted context omitted.

I don't think I understand your point, prolog is a logic programming language, some problems are easy to express like facts and rules so Prolog is a good solution, you can see examples in this HN thread of real usage. It is like recursion, some problems can be solved nice with recursion but you do not use recursion everywhere. Also you can use a library in your favorite programming language and not use prolog, exampl…

The examples I see are what I'd call "lab puzzles" and not practical real-world enough. I invite you to point out a specific example that's highly practical/realistic.

Did you see the real world uses? like prolog was and may still be used in Windows? The puzzle examples are for educational purpose.

Again I am just a noob, I learned Prolog and did some basic things years ago, a cool page I used to learn was this tutorial that implements a text based game , more refreshing then the tutorials with puzzles or the familiry

http://www.amzi.com/AdventureInProlog/a1start.php

The situation is maybe similar with GA(genetic algorithms) when you learn it you have some simple examples, when you want to solve a real problem things get complex fast(how to encode the problem,what fitness function should I use ...)

Re: The Power of Prolog

#155

Post by collyw »

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

Where do you work that you get so little imperative languages?

Re: The Power of Prolog

#156

Post by arca_vorago »

FractalLP wrote: post #62
arca_vorago wrote: post #10

Earlier quoted context omitted.

It's still going strong in the industrial side of things (like SCADA). You just don't hear much about it.

I've never heard of Prolog alongside SCADA. Can you be more specific? Like in a plant or what?

You know, I'm not sure where I got that from. Maybe I was confusing prolog with the ladder logic, or other languages from IEC 61131-3? I'm really not sure... but after some duckduckgoing I've come to the conclusion I was wrong in my previous statement... sorry.

Re: The Power of Prolog

#157

Post by kbp »

chriswarbo wrote: post #150
tabtab wrote: post #141

Earlier quoted context omitted.

That's another thing: "high-meta" languages allow individual developers to re-invent the flow-control wheel in their own image (personal preferences). Consistency is often more important for team readability than factoring (compact code). One man's "clever" can be another's spaghetti code. What works well for individual projects often doesn't scale to larger and often-changing teams.

That argument can certainly be applied to Lisps, with their extensive macro systems, but that's mostly orthogonal to programming paradigm. Lisps aren't necessarily functional: Common Lisp is highly imperative, and even Scheme is 'the ultimate imperative' https://dspace.mit.edu/handle/1721.1/5790 ! As for that `ifThenElse` example, there's nothing "meta" going on at all and there's no fancy control flow: it's just a (…

> and even Scheme is 'the ultimate imperative' https://dspace.mit.edu/handle/1721.1/5790 !

Scheme isn't, lambda is. That paper is about how lexical closures alone are enough to simulate a lot of imperative concepts like assignment, loops, and gotos (they do cheat and use set! in a couple places, but the point of the paper is how much lambda application can do all on its own). Your broader point about Lisps not being particularly functionally oriented is correct, though; they're some of the most unopinionated languages you could imagine.

Re: The Power of Prolog

#158

Post by kbp »

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

> Or, as an old adage goes, "If it compiles, it works."

This isn't said about the declarative nature of languages so much as it is about the benefits of powerful static type systems, in my experience.

It's quite easy to write Prolog programs that look right (to me, someone who doesn't know Prolog well) but that compile, successfully run to completion, and produce incorrect results (or don't terminate). In Haskell, the compiler actually rejects a huge amount of incorrect programs that I thought were going to work (and the fact that I thought that shows that the declarative nature of the code wasn't sufficient) and then once the typechecker is finally happy, the code often does actually work without further debugging (this is a common experience, and what the saying is referring to, I believe); in Prolog (or dynamically typed functional languages like Scheme), there's very little of that, and I'm left to catch most bugs on my own (even if like you said there won't be as many because they'd be so obvious in the first place).

Prolog might be exceedingly clear once you learn how to read it and it might eliminate errors that way, but "if it compiles, it works" is a terrible description of that. "If it looks right to someone who knows the language well, it works" is much closer, but not as punchy. The entire point of the original saying is that you don't need the experience with the language to get that, because the compiler itself will tell you if you're wrong when your types won't line up.

Re: The Power of Prolog

#159

Post by FractalLP »

arca_vorago wrote: post #156
FractalLP wrote: post #62

Earlier quoted context omitted.

I've never heard of Prolog alongside SCADA. Can you be more specific? Like in a plant or what?

You know, I'm not sure where I got that from. Maybe I was confusing prolog with the ladder logic, or other languages from IEC 61131-3? I'm really not sure... but after some duckduckgoing I've come to the conclusion I was wrong in my previous statement... sorry.

No problem. Ladder logic and C I can definitely see, but SCADA would have blown my mind :)

Re: The Power of Prolog

#160

Post by the_af »

tabtab wrote: post #135
the_af wrote: post #69

Earlier quoted context omitted.

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

I don't understand your example (and I don't understand why you consider lambdas silly), but more importantly: if most of the world -- by which I mean, modern language designers and practitioners -- seems to be going one direction, and you insist in staying put, aren't you at least a bit worried you might be wrong about it? "It" being the partial adoption of FP idioms and features in this case.
Post reply on HN