Prolog interpreter is unlikely to be able to meet your performance needs although it would be a great ui. Search datalog and bdd and you should be able to find some good research and tools using bdd to support source code analysis related queries.
I thought about using datomic for this before. I've seen a Java based bdd data log tool for pointer analysis. Though it was hard to play with Iirc. I think it would be slow but good for prototypes.
tl;dr - I'm upset because the raison d'etat for Go's name doesn't exist.
Correct, no -- practical, probably. No matter how many gophers swear that {searchterm} + go returns just as good of results as {searchterm}+golang, it just isn't true.
Maybe I'm just bitter because the reason Go was named Go was because -- and obviously I'm paraphrasing here... "we thought Oogle would be a really cool name for a debugger."
Years later, here I am stuck searching {some search term} + GOLANG and step debugging with GDB.
The worst part though is hearing people tell me, "Oh you know what, I realize how powerful printline statements and unit tests are for debugging! I don't even miss a debugger!" Or-- "have you tried GDB? Go Supports GDB! I haven't used it -- but it exists!" GDB is a god damn hate machine. And the chorus of "print statements are good enough" is motivated reasoning at its finest.
Wow, just last week I was thinking how useful having embedded prolog in Go would have been, for a very particular problems that maps very well in Prolog. I'm super excited by this!
What problems are they? I'm interested in Prolog but never encountered something I thought would be a good fit (or perhaps I'm not thinking about it the right way)
Some examples: Combinatorial optimization problems, timetabling tasks, reasoning engines, rule-based systems for the medical industry, recommender systems etc.
First of all, this is great work! Hopefully, it will implement the Warren Abstract Machine[1] in the future, since it generally leads to more efficient interpretation. E.g. both SICStus and SWI-Prolog implement a version of the WAM.
Prolog is my favorite example language I use to convey the concept of how different programming paradigms lend themselves to different types of problems. After learning the syntax and mechanics prolog seems like a ridiculous language that was written to win a drunken bet with a philosopher. but given the right problem it feels like using black magic.
Solving Einstein's riddle[1] is trivial in prolog for example. But perhaps only because we know that the answer can be determined from the premises.
23 comments
[ 3.8 ms ] story [ 64.9 ms ] thread[1] https://www.youtube.com/watch?v=G_eYTctGZw8
Either way, email's in my profile. We should talk.
https://github.com/andrewchambers
Correct, no -- practical, probably. No matter how many gophers swear that {searchterm} + go returns just as good of results as {searchterm}+golang, it just isn't true.
Maybe I'm just bitter because the reason Go was named Go was because -- and obviously I'm paraphrasing here... "we thought Oogle would be a really cool name for a debugger."
Years later, here I am stuck searching {some search term} + GOLANG and step debugging with GDB.
The worst part though is hearing people tell me, "Oh you know what, I realize how powerful printline statements and unit tests are for debugging! I don't even miss a debugger!" Or-- "have you tried GDB? Go Supports GDB! I haven't used it -- but it exists!" GDB is a god damn hate machine. And the chorus of "print statements are good enough" is motivated reasoning at its finest.
[1] https://en.wikipedia.org/wiki/Warren_Abstract_Machine
Solving Einstein's riddle[1] is trivial in prolog for example. But perhaps only because we know that the answer can be determined from the premises.
1) http://en.m.wikipedia.org/wiki/Zebra_Puzzle
http://swish.swi-prolog.org/example/houses_puzzle.pl