|
|
|
|
|
by shawa_a_a
597 days ago
|
|
I would second Prolog as mind-blowing. I've found you're typically confronted with fully engaging with the core of whatever problem you're solving, and only that core. This is probably what can make it so frustrating sometimes as you have no option but to work out the hard stuff nearly immediately; not to mention that unconsidered edge cases, mistakes can cause some pretty opaquely wrong results, or the query not terminating, which can make conventional debugging pretty difficult. The guarantees you get with using the 'pure' core of Prolog do open up some really interesting avenues though, for example Scryer's debugging library is quite neat in affording _semantic_ debugging: https://www.scryer.pl/debug Just some additional commentary too - I think this post quite misrepresents it with some of the comparisons. Prolog at its core is SLD Resolution [1] (a form of search) over Horn Clauses [2] (first order logic). Queries posted to the runtime are attempts to find a set of values which will satisfy (cause to be true) the query – whilst SQL is founded on relational algebra which more closely aligned with set theory. Whilst there's probably some isomorphism between satisfying/refuting a logical predicate, and performing various set operations, I'd say it's a bit of a confusion of ideas to say that SQL is based on 'a subset of Prolog'. The author might be thinking about Datalog [3], which is indeed a syntactic subset of Prolog. [1]: https://en.wikipedia.org/wiki/SLD_resolution
[2]: https://en.wikipedia.org/wiki/Horn_clause
[3]: https://en.wikipedia.org/wiki/Datalog |
|