3 ms·
Something I always wondered about Prolog: if you're not defining how the program executes (but rather, what it should do), how do you know if something (a const
by chrisshroba 5y ago
Something I always wondered about Prolog: if you're not defining how the program executes (but rather, what it should do), how do you know if something (a constraint) you're asking for is extremely expensive under the hood? Sure you can run the program and see how long it takes, but if your program is based on real-time data it seems like it would be difficult to have any idea if your program will consistently yield proper results in a reasonable amount of time.
Do I misunderstand something about how Prolog and other constraint-based programming languages work?
- dwohnitmok 5y agoNope you're totally right that at some point you have to understand how the Prolog engine actually tries to evaluate things. This is not just for performance, but as I allude to in the case of IO, sometimes necessary for correctness. Usually this is just knowing that Prolog does backtracking, but it can be more involved depending on your performance needs. But often for a complicated enough project you will find yourself resorting to cut quite a bit. What I meant by execution is more around how it feels to program in Prolog. So many things that feel like "hmmm I need to call this function and then this function here", etc. in other programming languages are just "oh, I just need to substitute a variable here" in Prolog. It's a very interesting world to remove the entire concept of "return" from your lexicon (e.g. a function returning a value).
- segmondy 5y agoYou can optimize the search, a naive solution would brute force all possible solutions. But you can cut the search short, so adding cuts in the right places will speed it up even tho it doesn't make it pure. You can also memoize results. The difference between a naive and an optimized solution in prolog is orders of magnitude difference.