3 ms·

It might be easier to learn prolog, if non-essential costs were removed, by using a more familiar language as a wrapper[1], or for metaprogramming. Prolog's va

It might be easier to learn prolog, if non-essential costs were removed, by using a more familiar language as a wrapper[1], or for metaprogramming. Prolog's value lies in its database core. But much of the cost of learning a new language is elsewhere, in dealing with yet another different set of ways to do familiar things. With prolog, those differences are relatively uninteresting, so why not punt? Not having to deal with "how do I read a csv file in prolog?" and such, frees time for richer ideas, like prolog search is a poor fit for most problems, but prolog is a nice language for writing problem-appropriate search. [1] https://github.com/yuce/pyswip https://github.com/yuce/pyswip

galaxyLogic 6y ago
That's my hunch too. Prolog is a different world and you still want to keep one foot in more mainstream languages. The idea should be use Prolog where it gives real advantages and use mainstream languages where it doesn't. So how do you divide your application into those two "islands"? Answer: Use persistent Datalog for database/persistence but do the rest in you bread-and-butter language. Basically saying replace SQL with Datalog. That is just what I think I'd like to do. I don't know what would be the most practical platforms to do that, which mainstream language + which Datalog database. Any recommendations?
- mncharity 6y ago
  No recommendations, sorry, merely a couple of thoughts. Prolog and datalog start out as rather different beasts, though prolog tabling gets them closer. It's an area of current research[1]. A datalog implementation can serve as DSL, learning tool, and/or efficient solver of large problems. For the first two, most languages have a little datalog implementation or three. For datalog engines, perhaps Z3 and its fixpoint engine from python?? Or maybe Soufflé from python?? But I really have no idea what's plausible. I too would be interested. > database/persistence That's something with a big diverse active market. Datalog engines, not so much. So I'm unclear that datalog is a place to go for that? But I also pay no attention to non-open-source offerings. [1] https://arxiv.org/pdf/1909.08246.pdf https://arxiv.org/pdf/1909.08246.pdf

galaxyLogic 6y ago

That's my hunch too. Prolog is a different world and you still want to keep one foot in more mainstream languages. The idea should be use Prolog where it gives real advantages and use mainstream languages where it doesn't. So how do you divide your application into those two "islands"? Answer: Use persistent Datalog for database/persistence but do the rest in you bread-and-butter language. Basically saying replace SQL with Datalog. That is just what I think I'd like to do. I don't know what would be the most practical platforms to do that, which mainstream language + which Datalog database. Any recommendations?

mncharity 6y ago
No recommendations, sorry, merely a couple of thoughts. Prolog and datalog start out as rather different beasts, though prolog tabling gets them closer. It's an area of current research[1]. A datalog implementation can serve as DSL, learning tool, and/or efficient solver of large problems. For the first two, most languages have a little datalog implementation or three. For datalog engines, perhaps Z3 and its fixpoint engine from python?? Or maybe Soufflé from python?? But I really have no idea what's plausible. I too would be interested. > database/persistence That's something with a big diverse active market. Datalog engines, not so much. So I'm unclear that datalog is a place to go for that? But I also pay no attention to non-open-source offerings. [1] https://arxiv.org/pdf/1909.08246.pdf https://arxiv.org/pdf/1909.08246.pdf