[HN Gopher] Introduction to Datalog
___________________________________________________________________
Introduction to Datalog
Author : jgrodziski
Score : 292 points
Date : 2023-02-15 08:41 UTC (14 hours ago)
(HTM) web link (blogit.michelin.io)
(TXT) w3m dump (blogit.michelin.io)
| wslh wrote:
| In the last few months the mention of Datalog has increased, I
| wondered how it differed from graph databases and found a clear
| answer in SO [1]. I am not an incumbent but found graph databases
| and clause approaches interesting.
|
| [1] https://stackoverflow.com/questions/29192927/a-graph-db-
| vs-a... (2015)
| cmrdporcupine wrote:
| You might be interested in https://relational.ai/
|
| Treats graph edges as binary relations ("graph normal form"),
| has a Datalog-ish language. Built for managing large
| interconnected knowledge sets in a declarative way.
|
| I recommend this talk:
| https://www.youtube.com/watch?v=WRHy7M30mM4
| felixyz wrote:
| Great project, not open source alas. This is another great
| talk about RelationalAI (and its precursor), highlighting how
| using powerful databases can simplify complex applications:
| https://www.hytradboi.com/2022/experience-report-building-
| en...
| cmrdporcupine wrote:
| Not speaking on behalf of the company, but... It remains
| difficult to do open source and also pay people.
| noduerme wrote:
| That's a really neat example of something I'm not familiar
| with. Going up a tree from child to parent is often the
| heaviest part of dealing with regular datasets, and usually
| requires a mix of queries and application logic. The idea of
| flattening the data along some pattern like that is of course
| always _possible_ in a relational db, but it 's not usually
| efficient, especially not for heavy writing. Lateral joins and
| window partitions can help. But this seems like an interesting
| approach to removing the app code completely.
| refset wrote:
| XTDB, which is mentioned in the post, is subtly different from
| the other Clojure-based Datalog systems in this respect,
| because its Datalog engine executes in terms of multi-way joins
| using a "Worst-Case Optimal Join" implementation that is ideal
| for graph processing (vs. a tree of binary hash joins).
| Therefore, based on statistics and query planning heuristics,
| it will often perform graph pattern matching before resolving
| the logic/horn clauses. (source: I work on the XTDB team)
| eternalban wrote:
| Interesting architecture:
|
| https://raw.githubusercontent.com/xtdb/xtdb/master/docs/conc.
| ..
|
| Btw, is that 'RocksDB or ?' for the local store current or
| other storage engines can get plugged in?
|
| p.s. this is datomic's architecture for comparison.
|
| https://docs.datomic.com/on-prem/images/clientarch_orig.svg
| refset wrote:
| Hmm, it seems there's some SVG rendering issue when viewing
| directly. It should say "LMDB" in that empty spot. It
| renders okay for me on the GitHub readme:
| https://github.com/xtdb/xtdb (and here
| https://docs.xtdb.com/concepts/what-is-xtdb/)
| flyingsilverfin wrote:
| I work on TypeDB (https://vaticle.com/typedb), and it sits
| somewhere at this intersection. The exposed query language has
| elements of both logic programming constructs and graph-like
| structures. Both amount to a kind of "constraint" programming.
| rapnie wrote:
| A quick peek shows it seems along similar lines as TerminusDB
| sorta kinda, but they have WOQL [0]. At this time I start to
| worry again about all the different kinds and flavours of
| query languages that are emerging.
|
| [0] https://en.wikipedia.org/wiki/TerminusDB#Query_language
| convolvatron wrote:
| why would you worry? this space has been occupied by the
| default for so long, its refreshing to see people
| experiment with what might be possible.
| cmrdporcupine wrote:
| Agree, only concern is that whatever emerges here has
| conceptual clarity and doesn't get bastardized by people
| who haven't studied the foundations of the relational
| model.
|
| I have this fear because there's a history of that with
| novel query languages and DB platforms tossing in
| network/hierarchical/"document"/object-oriented features,
| and creating a dog's breakfast which loses the
| compositional/expressive power of the relational algebra.
| Think MongoDB or Redis. Conceptually a big mess.
|
| RDF itself has a history of this as well. Appeals to
| novelty.
|
| Or even Google's F1, which smashes hierarchical tree-
| structured protobufs into a SQL DB, and so has really
| weird behaviour on joins and projections.
|
| Well, whatever, you know my opinions on this stuff, I
| think :-)
|
| At this point I'd settle (or ask for) for a network
| available tuplestore which just receives relational-
| algebraic operators from a client, and
| optimizes/executes, and returns pure tuples, and the
| client-side could formulate whatever query language (or
| API) it wanted on top of that. I started playing with
| building something like that between the two jobs, but
| never got far.
| felixyz wrote:
| I really like TypeDB! Haven't been able to use it for
| anything serious yet, but have a couple of project brewing
| where it might fit :)
| felixyz wrote:
| I did an interview [1] with Kevin Feeney, one of the founders
| (no longer active) of TerminusDb, which goes into some depth
| about the difference between RDF stores and (property) graph
| databases, where the former is more closely aligned with
| datalog and logic programming. There are links to a really
| excellent series of blog posts by Kevin on this topic in the
| show notes.
|
| [1] https://thesearch.space/episodes/5-kevin-feeney-on-
| terminusd...
| westurner wrote:
| With RDF* and SPARQL* ("RDF-star" and "SPARQL-star") how are
| triple (or quad) stores still distinct from property graphs?
|
| RDFS and SHACL (and OWL) are optional in a triple store,
| which expects the subject and predicate to be string URIs,
| and there is an object datatype and optional language:
| (?s ?p ?o <datatype> [lang]) (?subject:URI,
| ?predicate:URI, ?object:datatype, object_datatype,
| [object_language])
|
| RDFS introduces rdfs:domain and rdfs:range _type_
| restrictions for Properties, and rdfs:Class and
| rdfs:subClassOf.
|
| `a` means `rdf:type`; which does not require RDFS:
| ("#xyz", a, "https://schema.org/Thing") ("#xyz",
| rdf:type, "https://schema.org/Thing")
|
| Quad stores have a graph_id string URI "?g" for Named Graphs:
| (?g ?s ?p ?o) ("https://example.org/ns/graphs/0",
| "#xyz", a, "https://schema.org/Thing")
| ("https://example.org/ns/graphs/1", "#xyz", a,
| "https://schema.org/ScholarlyArticle")
|
| There's a W3C CG (Community Group) revising very many of the
| W3C Linked Data specs to support RDF-star:
| https://www.w3.org/groups/wg/rdf-star
|
| Looks like they ended up needing to update basically most of
| the current specs: https://www.w3.org/groups/wg/rdf-
| star/tools
|
| "RDF-star and SPARQL-star" (Draft Community Group Report; 08
| December 2022) https://w3c.github.io/rdf-star/cg-
| spec/editors_draft.html
|
| GH topics: rdf-star, rdfstar: https://github.com/topics/rdf-
| star, https://github.com/topics/rdfstar
|
| pyDatalog does datalog with SQLAlchemy and e.g. just the
| SQLite database: https://github.com/pcarbonn/pyDatalog ; and
| it is apparently superseded by IDP-Z3:
| https://gitlab.com/krr/IDP-Z3/
|
| From https://twitter.com/westurner/status/1000516851984723968
| :
|
| > _A feature comparison of SQL w / EAV, SPARQL/SPARUL_,
| [SPARQL12 SPARQL-star, [T-SPARQL, SPARQLMT,]], Cypher,
| _Gremlin, GraphQL, and Datalog would be a useful resource for
| evaluating graph query languages._
|
| > _I 'd probably use unstructured text search to identify the
| relevant resources first._
| forks wrote:
| I love The Search Space. Waiting patiently for new episodes!
| ianpurton wrote:
| So I struggled with this.
|
| I guess the intention is to be better than SQL but then I was
| left with "under which circumstances?".
|
| With that question in mind I didn't feel the article addressed
| the issue.
|
| The author might do better to think in terms of "what burning
| problem are we trying to fix and how did we fix it".
| bambataa wrote:
| I had the exact same reaction.
|
| I did a bit of reading about Datalog and I get that it's useful
| in things like static analysis where you get the fixed point
| analysis for free, but apart from that I am not really sure why
| I'd use it.
| maweki wrote:
| The main reasons I'd say are the very intuitive JOINs and
| queries. Like you give some partial relation and you get
| every "fit". So as long as you mostly do equalities in JOIN
| and WHERE, the queries will be very intuitive and obvious to
| the layperson.
|
| If you work with VIEWs or CTEs a lot, then Datalog is your
| friend, as every derived relationship is just a VIEW. If you
| like to encapsulate and reuse queries, then Datalog is ideal.
| We had plenty discussions on HN about SQL code reuse. Not an
| issue in Datalog.
|
| And lastly, there are many ways to compile Datalog programs
| to "executables" that take maybe a few CSV-files as input and
| give you the results. I'm not saying that this would be
| always faster than loading the CSVs into SQLite and running
| SQL against the data, but a lot of work has been done on
| Datalog query optimization and compilers can emit very
| efficient code.
| samuell wrote:
| > If you like to encapsulate and reuse queries
|
| This is what I always thought was the main benefit.
|
| You are able to much easier raise your level of
| abstraction, by building up a vocabulary of definitions,
| and model your further queries (or definitions) using them.
| crabbone wrote:
| I'm not the author, and I don't know how author would answer
| this question, but some things are really on the surface:
|
| 1. Modularity. In Datalog it's very easy to name a common
| (sub-)query and reuse it in multiple queries. You can have
| stored procedures / functions in SQL, but the syntax is very
| different implementation to implementation and users are
| typically afraid of using the feature (the SQL/PSM does not go
| far enough to define what users would normally want). Also,
| SQL/PSM is an _imperative_ extension of otherwise declarative
| language. The two just don 't work well together.
|
| 2. Structures other than primitives and tables (you get lists,
| vectors, hash-maps and sets, but you can also make your own). A
| lot of practical SQL extensions also offer some of these
| structures, but they aren't in the standard.
|
| 3. Operations on primitive types fall into the same category /
| work in the same way as operations on complex types. I.e.
| select / update / insert / delete in SQL only apply to tables,
| but strings or numbers don't work in the same way. It's more
| uniform in Datalog (not 100%, but still better).
| anon291 wrote:
| Sql doesn't compose at all. You can't take two sql programs and
| combine them with a single operator and get a new program.
|
| In datalog you can. Either by using the comma or semicolon
| operator.
| crabbone wrote:
| You are thinking about the declarative part. SQL/STP, the
| standard that's the basis for definition of the imperative
| part of SQL (stored procedures) can compose in a similar way
| (eg. you can call a stored procedure from a stored
| procedure), but the standard doesn't go far enough, and so
| every practical database has its own extensions which deters
| people from using stored procedures because they'd end up
| with non-portable code.
| sirwhinesalot wrote:
| That's a good point, to be honest I'm not sure there's a
| particularly good answer to that beyond "it's a much better
| underlying model". SQL is an ugly bastardization of the
| relational model, whereas Datalog is a clean application of the
| logical model to the relational setting.
|
| One thing that's really nice about Datalog is that it puts the
| focus on modelling relations between data instead of "tables"
| which often end up with a jumble of data and then need to be
| normalized to work properly. It pushes you into good structures
| by default, which is a really good property to have. It's also
| much much simpler than SQL, no need to think in terms of inner
| joins and outer joins and whatever else, it is all relations.
|
| It also easily produces derived data from existing data,
| without needing any kind of procedural process, and is highly
| composable.
|
| It's not so much that it's solving a burning problem than SQL,
| it's just better than SQL...
|
| (note: the clojure syntax used in that page is much more
| confusing than the native Datalog syntax IMO)
| zh217 wrote:
| Another problem with Clojure-based Datalog is performance.
| Yet another is you are pretty much tied to the Clojure
| ecosystem. And I don't really like the Clojure-fused Datalog
| syntax either. These pains spurred me to write my own:
| https://docs.cozodb.org/en/latest/ (FOSS), and so far I'm
| satisified with my own work.
| arohner wrote:
| What is the performance problem?
| conor-23 wrote:
| A researchy perspective: Datalog was invented to extend
| relational algebra with recursion. Since it started out as an
| academic tool, people have been studying recursion-specific
| optimizations you can do for decades so it is extremely well
| suited to recursive use-cases e.g. iterative graph algorithms.
| Using Datalog for network algorithms won the thesis award in
| databases almost 20 years ago
| https://boonloo.cis.upenn.edu/papers/boon_interview.pdf .
| tejtm wrote:
| This is the answer I subscribe to. CTEs and recursive CTEs
| are SQL's answer to a limitation of plain relational algebra;
| no loops.
|
| CTEs are a great and most welcome addition to SQL but they
| are a bolt-on patch as compared with Datalog where it is a
| core feature.
| yaantc wrote:
| In 2021 Google introduced Logica, a Datalog variant. In their
| introduction blog they contrast it with SQL, so this may answer
| your question:
|
| https://opensource.googleblog.com/2021/04/logica-organizing-...
|
| In short, it's easier to compose (and decompose), which helps
| with complex queries that can be assembled from simpler,
| independently tested parts.
|
| No personal experience in this, I just remembered that blog
| contrasting Datalog and SQL.
| mmcdermott wrote:
| > I guess the intention is to be better than SQL but then I was
| left with "under which circumstances?".
|
| The way I see it, SQL's great strength as a query language is
| selection and projection whereas Datalog's great strength is
| inference.
|
| It takes a shift in mindset to take advantage of inference.
| I've started using Datalog when analyzing unfamiliar codebases.
| So I might set up something like:
| writes_to(microservice1, db1). writes_to(microservice2,
| microservice1). writes_to(microservice3,
| microservice2). depends_on(X, Y) :- writes_to(X,
| Z), depends_on(Z, Y). depends_on(X, Y) :- writes_to(X,
| Y).
|
| Allowing you to query something like:
| depends_on(microservice3, X)
|
| and get back db1, microservice1 and microservice2. Of course,
| you can ultimately do this in SQL as well, but it's far more
| compact in Datalog.
|
| Which brings me to the second half of the motivation - the
| principal advantage to the logical database model is the open
| world assumption. The relational model in practice tends to be
| fairly buttoned down - data is expected to suit a particular
| schema (which has its own advantages as a transactional
| system). This makes it easy to extend a logical database and
| ask more questions without changing the fact formats already
| specified.
|
| Of course, I can ultimately do all the things that feel natural
| in Datalog in SQL. I can work through queries like the one
| above by building out the data model and writing recursive
| CTEs. It's about strengths, not possibilities which I suppose
| brings me back to why SQL 'won'. A disproportionate amount of
| code is written for transactional line-of-business systems.
| It's really not hard to see why the validation layer and
| transactional focus would win in those areas.
| dgb23 wrote:
| One of the biggest advantages is re-use, extensibility and
| being robust to change, because you define things bottom up.
| Think of aggregates as "hashmaps with typed keys" rather than
| "structs with places in them".
|
| Aggregates are implicit groupings, not explicit slots. This
| wards you from risk of change and speeds up your feedback loop
| of making changes and experimenting with ideas. Plus you can
| compose new aggregate variants out of the same primitives
| (attributes) which is a fairly typical use-case.
|
| Another is query composition. I'm more familiar with SQL and
| I'm somewhat comfortable with writing nested queries. But we
| all know how both query builders and similar are often hard to
| re-use and compose. With these datalog dialects, composition,
| refactoring and extraction of logical units is much more
| straight forward, even as a beginner. Queries are "flat", and
| consist clauses that can be moved around and composed. Think of
| having more associative and commutative operations.
|
| On top of these, the mentioned technologies (in the article)
| are temporal and support time travel out of the box. That's
| something you can do on top of SQL of course but it's quite
| powerful to have it in-built as a primary feature. Whenever you
| have an application that does things like (non-exclusive),
| reporting, undo, revisions etc. You might want that.
| ekidd wrote:
| > _I guess the intention is to be better than SQL but then I
| was left with "under which circumstances?"_
|
| Excellent question.
|
| Two of the most common use cases for databases are
| "transactional processing" (manipulating small numbers of rows
| in real time) and "analytical processing" (querying enormous
| numbers of rows, typically in a read-only fashion).
|
| SQL is generally fine for transactional workloads.
|
| But analytical queries sometimes involve multi-page queries,
| with lots of JOINs and CTEs. And these queries are often
| automatically generated.
|
| And once you start writing actual multi-page "programs" in SQL,
| you may decide that it's a fairly clunky and miserable
| programming language. What Datalog typically buys you is a way
| to cleanly decompose large queries into "subroutines." And it
| offers a simpler syntax for many kinds of complex JOINs.
|
| Unfortunately, there isn't really a standard dialect of
| Datalog, or even a particular dialect with mainstream traction.
| So choosing Datalog is a bit of a tradeoff: does it buy you
| enough, for your use case, that it's worth being a bit outside
| the mainstream? Maybe! But I'd love to see something like
| Logica gain more traction: https://logica.dev/
| felixyz wrote:
| > then I was left with "under which circumstances?"
|
| Foremost, Datalog has great compositionality, which is one of
| SQL:s big weaknesses (it was designed with completely different
| goals). Also, things like recursive queries are completely
| natural in Datalog, whereas in SQL they are bolted on with
| recursive common table expressions.
| refset wrote:
| > Datalog has great compositionality, which is one of SQL's
| big weaknesses
|
| There's a good write-up on this aspect (amongst others) here:
| https://www.scattered-thoughts.net/writing/against-sql/
|
| > recursive queries are completely natural in Datalog,
| whereas in SQL they are bolted on with recursive common table
| expressions
|
| And similarly: https://github.com/frankmcsherry/blog/blob/mas
| ter/posts/2022...
| z5h wrote:
| I've been using Prolog a bunch recently, and also embedded and
| extended MicroKanren in a project. Something I came to appreciate
| was that Prolog's depth-first search, and Kanren's lazy stream
| approach are good with memory even when generating/searching
| through infinite solutions. It is my understanding that Datalog,
| on the other hand, will iteratively expand a set of data. Isn't
| this a problem?
| dataengineer56 wrote:
| This is a cool concept but I'm not sure I'd fancy upskilling a
| team of SQL analysts to use this.
| cmrdporcupine wrote:
| Many SQL analysts are wasting their skills performing mental
| and syntactical gymnastics to get around the limitations of SQL
| in order to grasp at the actual conceptual elegance that lays
| underneath it. Most people who are writing SQL for a living
| already understand at least some part of what makes the
| relational model powerful. But SQL is relatively poor tool for
| accessing it.
|
| I personally don't find the Sexpr-based syntax of Datomic's
| variant of Datalog all that useful here, and yeah, maybe
| someone working in SQL for a living would struggle at first
| with that syntax. But it's not intrinsic to the model itself.
| Have a waltz through my employer's documentation and see what
| you think: https://docs.relational.ai/rel/primer/overview
|
| I think it's quite understandable (if a bit terse) and many
| people doing SQL for a living would appreciate the ability to
| better compose and structure things in this way, not to mention
| the ability to handle transitive / recursive relationships in a
| less awkward way.
| anon291 wrote:
| Whatever language this is... This is not datalog. This looks like
| a particular implementation of datalog in closure.
|
| Actual datalog looks like prolog.
| cmrdporcupine wrote:
| In reality, people are using "datalog" for a genre of datastore
| concepts based around horne clauses, or, basically relations +
| implicit joins. Datalog as a subset or dialect of prolog is
| only one variant of this. And Datomic has made an sexpr-
| syntaxed variant built around binary relations popular. To the
| point where some people in this thread can't seem to tell the
| two apart.
|
| I am more interested in the general category of relational data
| model + logic programming than I am in any purity about Datalog
| in particular. In particular I'm very excited by
| "data/knowledge + behaviour sitting in a tree, k-i-s-s-i-n-g"
| bogomipz wrote:
| Thanks. Is Datomic also a dialect of Prolog then?
| cmrdporcupine wrote:
| No, and I wouldn't call Datalog a dialect of Prolog either
| necessarily. It's more like, classic Datalog syntax looks
| Prolog-ish (similar syntax, and is kind of a subset of
| Prolog). And you can do Datalog-type stuff in Prolog. But
| from what I've read of Datomic it's got a totally different
| syntax, but similar semantics to Datalog .. but not
| Prolog...
|
| Basically, Prolog can do more than Datalog. Datalog is
| like, some subset of concepts of Prolog, but specialized
| for relational data queries, so it can achieve some
| optimizations and focus on data retrieval only.
|
| Is that confusing enough?
| dragonwriter wrote:
| > No, and I wouldn't call Datalog a dialect of Prolog
| either necessarily. It's more like, classic Datalog
| syntax looks Prolog-ish (similar syntax, and is kind of a
| subset of Prolog).
|
| Datalog originated specifically as a restricted subset of
| Prolog, which is why the "classic" syntax looks prolog-
| ish.
|
| > Basically, Prolog can do more than Datalog. Datalog is
| like, some subset of concepts of Prolog, but specialized
| for relational data queries, so it can achieve some
| optimizations and focus on data retrieval only.
|
| Datalog is a purely declarative, non-Turing complete
| subset of Prolog, removing the imperative features and
| assuring termination. This gives up lots of power,
| obviously, but it also, well, provides a termination
| guarantee. Removing imperative features (cut) from Prolog
| also means that Datalog implementations can use different
| (or multiple, switchable) strategies, while differing in
| what kinds of data sets and queries they perform well on,
| not correctness.
| refset wrote:
| > Datalog implementations can use different (or multiple,
| switchable) strategies
|
| Including distributed strategies, as seen in Bloom
| http://boom.cs.berkeley.edu/
| muattiyah wrote:
| ICYMI, there's an excellent interactive introduction to `datalog`
| that's referenced in the article's references.[0]
|
| Last time I used `datalog` was years ago, I was developing an
| internal interactive tool that was used to compare different
| approaches to solving a certain problem at my employer. I used
| `datascript`[1] by way of clojurescript to store all experiment
| data and then interrogated the `datascript` DB via `datalog`.
| This is something I always remember fondly.
|
| [0] https://www.learndatalogtoday.org/ [1]
| https://github.com/tonsky/datascript
| pavlov wrote:
| As mentioned in the article, Datomic is a database that uses
| Datalog as its query language:
|
| https://docs.datomic.com/on-prem/query/query.html#why-datalo...
|
| (Some ten years ago worked at a startup that used Datomic. It
| seemed to work great, although the only queries I ever needed to
| add to the system were simple copy-paste hacks of existing ones,
| so I never got to dive into Datalog.)
| dmitriid wrote:
| Datascript is the open source analog for Clojure, ClojureScript
| and JS: https://github.com/tonsky/datascript
| mpenet wrote:
| 'ish.
|
| datahike would be the closest to datomic in terms of
| features/implementation (support for as-of, transactor etc).
|
| Then in terms of maturity I think the choice is between xtdb
| and datascript, both are very solid/maintained but they are
| also vastly different.
| simongray wrote:
| There are many open source alternatives in Clojure using this
| query language: https://github.com/simongray/clojure-graph-
| resources#datalog
| grose wrote:
| Datalog is great for representing authorization rules. Check out
| Biscuits, which are auth tokens with Datalog embedded in them.
| This article is what made it 'click' for me: https://www.clever-
| cloud.com/blog/engineering/2021/04/15/bis...
|
| I actually thought that Datalog was so cool that I went to learn
| Prolog and it completely changed the way I think about
| programming. Highly recommend trying out logic programming if you
| haven't before.
| burakemir wrote:
| Agree but also want to point out that people usually have a
| narrow view on "logic programming". Datalog can also be
| understood with out the top-down evaluation / resolution that
| is typically associated with prolog, which is why it is known
| to database researchers and in finite model theory. Prolog is
| great, but bottom up techniques to evaluate datalog are
| awesome, too, and would arguably also qualify as logic
| programming. It is rare to see this acknowledged.
| i_am_toaster wrote:
| Maybe it's just me but I find the SQL much easier to read in all
| the examples given.
| eunos wrote:
| Huh cool, I didnt realize it come from that Michelin.
| eddieroger wrote:
| I remember being surprised once that Michelin, like the star,
| was the same as Michelin, like the tire. It's really cool to
| see a company move beyond their core competency more than once
| in a meaningful way, even if the first time was to sell more
| tires. They have a really interesting blog that this is just a
| single article from.
| pbronez wrote:
| I believe they started the star ratings as a way to encourage
| people to drive more. They saw it as part of "Travel".
| julienchastang wrote:
| Yes, absolutely, as are the eponymous "Guide Michelin"
| (Guide vert) that conveniently fit in the glove compartment
| of your automobile. More people drive, more they consume
| tires.
| tannhaeuser wrote:
| The language discussed in TFA appears to be Datomic's proprietary
| Clojure DSL, but has nothing to do with Datalog/Prolog.
| dimitar wrote:
| It is a datalog dialect, and there a multiple open-source
| implementations: https://clojupedia.org/#/page/Datalog
| thiago_fm wrote:
| The problem with Datalog, and Clojure in general are the
| licenses. Terrible licenses.
|
| Everything is about Rich Hickey. Apache 1.0.
|
| Now that Nubank basically owns it and there's very little
| progress or activity as of late, I don't see why one would chose
| to use Clojure, Datalog etc.
|
| Also, a lot of functional programming concepts has been since
| added to big programming languages like Javascript and hell, even
| Java has lambdas now.
|
| I'm guessing that also hardcore FP people have moved on to
| Haskell. The ones that like LISP to Racket... and only people
| tied to the JVM in legacy projects are with Clojure.
| cmrdporcupine wrote:
| Datalog != Datomic.
|
| Datomic [?] Datalog
| refset wrote:
| It's true that this SPARQL-inspired view of Datalog as a
| triplestore query language is quite a narrow interpretation
| compared to something closer to the academic Prolog roots
| like https://souffle-lang.github.io/ - what do you feel are
| the most important differences?
| cmrdporcupine wrote:
| Disclaimer: I'm not a Datalog expert. I do work for a
| company that makes a relational graph knowledge management
| system (RelationalAI), that has some Datalog-type aspects,
| but I only dabble at the front-end/query-language end of
| that; I work on the storage layer. I've also never used
| Datomic or its offshoots. Yes from what I understand,
| Datomic works only with binary relations. Classic Datalog
| can work with full n-ary relations. (However any n-ary
| relation can be thought of, or logically recomposed, as a
| series of binary relations anyways, and vice-versa)
|
| Syntax also clearly is not the Prolog-ish syntax of Datalog
| "proper."
|
| But my point above is, Datomic is but one product and
| implementation of these concepts. It's a wrong take to make
| a statement like "The problem with Datalog, and Clojure in
| general are the licenses"; there is a field of many
| products, all with multiple licenses, and also weird to
| make this "Clojure" swipe, when there's only tangential
| connection between "Datalog" and "Clojure" based on one
| product (and its offshoots).
| refset wrote:
| Thanks for the insights and clarifications - I agree with
| all that completely :)
|
| I mainly responded because "Datomic [?] Datalog" is
| worthy of discussion in itself ...but I now realise this
| is probably the wrong subthread for that.
| [deleted]
| maweki wrote:
| What are the licensing issues with First-order Horn clause
| logic?
|
| Datalog is not a licensed product or software, the same way
| Answer Set Programming isn't.
| jjtheblunt wrote:
| Saying that Java has lambdas is vague:
|
| it's like confessing one doesn't know what a Lisp lambda
| implies, in particular creation of closures to capture free
| variables, since Java creates a copy of free variable values,
| rather than inform the code generator as to allocation of said
| free variables, in order to honor the closure-extended
| lifetimes from stack allocation to heap allocation (for
| example).
| casion wrote:
| > very little progress or activity as of late
|
| There's been equally frequent releases and updates, I'm not
| sure how you came to this conclusion?
|
| The best I can think of is that you're confusing core language
| updates with other tech. Clojure is structured differently than
| other languages, and core language/library updates are (and
| always have been) relatively rare while the surrounding
| ecosystem/tooling provided by the Clojure team is active.
| giraffe_lady wrote:
| > and only people tied to the JVM in legacy projects are with
| Clojure.
|
| You say this as if it's not an absolutely massive body of
| programmers. A lot of large companies are institutionally
| committed to JVM, and clojure has settled into a niche as the
| language teams within them use when they don't want to use
| java.
|
| I expect there are more people working on projects that fit
| that description than there are ones working in racket and
| haskell combined.
| dgb23 wrote:
| > Also, a lot of functional programming concepts has been since
| added to big programming languages like Javascript and hell,
| even Java has lambdas now.
|
| JavaScript was "functional" since the beginning. It always had
| statically scoped first class closures.
|
| But as you say, that's not very special anymore...
|
| If you want to do primarily FP with a data oriented touch you
| want stuff like:
|
| - immutable, persistent data structures
|
| - a comprehensive library around transforming these
|
| - expression based syntax
|
| - idiomatic (functional style code) performance is good
|
| - a comprehensive library around manipulating, composing and
| transforming functions
|
| - more stuff that I'm forgetting right now
|
| Clojure gives you all of that and _more_, such as a powerful
| REPL, macros, multiple dispatch, spec instrumentation, proper
| namespaces, ...
|
| Personally I write JS in a very straight forward, functional
| style. But the differences is still night and day in many
| dimensions. There are fundamental issues with the language that
| are unfortunately unfixable. Just having first class function
| objects isn't cutting it.
| armincerf wrote:
| XTDB is MIT and has clients for Java or HTTP if you don't want
| to write Clojure. Not every Datalog implementation is 'about
| Rich Hickey'
| beders wrote:
| Quick reminder that Clojure is available on the JVM, CLR, Node,
| browsers, stand-alone interpreter (Babashka), on the Erlang VM
| and there's a C++ impl. that is being worked on actively.
| samuell wrote:
| A bit related, just stumbled upon Flix, a functional JVM language
| with Datalog contraints and (somewhat?) Go-like concurrency:
|
| https://flix.dev
|
| HN Thread from 8 months ago:
| https://news.ycombinator.com/item?id=31448889
| refset wrote:
| Flix definitely looks interesting! For comparison, I ported the
| "Datalog Enriched with Lattice Semantics" example from that
| homepage to XTDB's (Clojure) Datalog after I saw it posted on
| HN originally:
| https://gist.github.com/refset/21b3fc1dec9a6928943073809e133...
___________________________________________________________________
(page generated 2023-02-15 23:00 UTC)