3 ms·

How does storing facts in the source code instead of a database make any practical sense? I mean I can hardly imagine a real-life scenario where the number of f

• deleted 8y ago
  [deleted]
• deleted 8y ago
  [deleted]
• ben-schaaf 8y ago
  Facts are both data and "source code". It's a fact that a user with id=0 has name=Bob. It's also a fact that the sqrt(x^2)=x or the http response code when a resource isn't found is 404. Some of those belong in databases, some definitely don't.
• brudgers 8y ago
  This isn't a real life example, but illustrates the sort of facts that are difficult to maintain in a BCNF relational database...and are still difficult to query in a non-BCNF relational database. Paper covers Rock Rock crushes Scissors Scissors cut Paper In Prolog we might encode that: wins(paper, rock). wins(rock, scissors). wins(scissors, paper). loses(X,Y) :- wins(Y,X) Relational databases are good for storing context-free facts. In table T, the interpretation of row R1 is independent of the contents of row R2. A practical real-life scenario for Prolog might be a "help wizard." The next step depends on what steps we have already tried (and not tried) and other kinds of state. The next step can be expressed as a Horn Clauses. X /\ Y /\ NOT Z -> Z NOT B /\ NOT W /\ X /\ Z /\ A /\ Q -> M etc. If the Prolog and the Horn Clauses look a bit like regular grammars, writing compilers is another area where Prolog has been applied historically. The first version of Erlang is an example, and some of Erang's design made more sense to me after learning a little bit of Prolog. But I am into learning mostly useless subjects.