Datalog queries are stored in EDN usually, and EDN highlighting is served by Clojure-mode.

I see. So you use the REPL for executing the queries?

What is a SQL-query-assisting library doing, that you still need something to do in the Datalog-as-data world?

My SQL workflow would be something like • Develop the queries separately, editing them in sql-mode and executing them in another Emacs buffer • When I’m happy with the query, I’d bring it to my HugSQL queries file I’m now experimenting with datalog in a non-clojure context, but I plan to use datascript and xtdb. Not sure if the above flow makes sense in the clojure + datalog context, but I just want a workflow where I experiment and iterate on the queries and bring the final queries to the application.

So, If I write the queries using EDN, as Ivan mentioned, inside the application, then I get all the IDE-ish features. Then the question would be how I execute them, which I thought would be REPLing them. I haven’t tried these yet so my ideas could definitely be half-baked.

"Experimenting with datalog in a non-clojure context" sounds punitively difficult. :-) In Clojure, the REPL works great for Xtdb; it is a super environment for experimentation. You do not need anything in the role of HugSQL. Combining Datascript and Xtdb might be perfectly reasonable, but Xtdb is a document database while Datascript is datoms (isn't it?) so I'm not sure how deep a similarity you cna infer from their respective datalog query interfaces. I have heard that Datomic is now free-of-charge (although not open source), so if you don't need a document database or require open source then you might find Datomic more Datascript-like than Xtdb is.

Thanks @U0HG4EHMH! I somehow found myself in a situation where I can’t avoid the “punitively difficult” experience 🙂 I’ll definitely check out the xtdb + REPL, as well as datomic! Cheers!

3 important historical works come to mind: "Java concurrency in practice", "Effective Java", and "Design Patterns". JCIP's author keynoted a Clojure conj and summarized by quipping that he had invented Clojure and Hickey had just followed his blueprints. "Effective Java" is a litany of problems self-inflicted by Java, and it's as if Hickey had gone down that list, tracing each one back to first principles and knocking it out. "Design Patterns" is a picture of a dystopian world that would exist without closures.

Two more works that could be regarded as historical documentation of the landscape pre-Clojure include the Spring Framework and Hibernate. They address glaring problems with Java that made Java unsuitable for practical use. Do you need Spring or Hibernate in Clojure? Not at all. So, did Clojure borrow anything from Spring or Hibernate?... no, not really. What a paradox! Hickey famously said that while making Clojure, "I did not invent *anything*" [transducers having come later and persistent data structures not being his invention]. When he solved a problem, he did so without inventing a language feature. Some of these solutions were already described, for Java, in JCIP or "Effective Java", but the advice was, in practice, darn near impossible for programmers to follow. In short, by copying well-established features very selectively, Clojure attained superpowers that other languages may have a hard time copying back. (Problems of this nature start with the very development process and also involve concurrency, privacy, serialization, iteration, inheritance, closed-vs-open extension, equality, dynamism, boilerplate, domain-specific-languages/code-generation, initialization, immutability, and reusability of data and code.)

Thank you very much!