This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # aws (9)
- # beginners (136)
- # boot (4)
- # cider (11)
- # clara (35)
- # clojure (337)
- # clojure-europe (5)
- # clojure-italy (3)
- # clojure-nl (2)
- # clojure-spec (9)
- # clojure-uk (112)
- # clojured (7)
- # clojurescript (93)
- # core-async (2)
- # cursive (30)
- # datomic (6)
- # duct (4)
- # emacs (2)
- # figwheel (1)
- # figwheel-main (7)
- # fulcro (153)
- # kaocha (1)
- # off-topic (12)
- # om-next (1)
- # pedestal (58)
- # planck (6)
- # re-frame (15)
- # reitit (11)
- # shadow-cljs (113)
- # spacemacs (1)
- # specter (3)
- # vim (8)
Over the next week or so, we're going to be working on a library to translate pull expressions into Clara rules productions. Any thoughts on that now could shape how this works.
The primary system I work on models tasks and data dependencies. Inputs and output for a task are described as pull expressions, and this allows us to compute task dependencies. We couldn't do this with raw Clara queries, since they model general computation so halting problem yada yada.
Pull expressions are a really nice, natural way to describe the shape of data wanted, IMHO.
We are moving to Clara handling more of the computation, because its truth maintenance property solves a lot of problem for us, and one of the new things we want to know is when a tasks inputs have changed, in order to retrigger our task.
So we're building this library to have Clara compute the inputs for a task in real time and update them as new data arrives.
@U0ECYL0ET sounds like an interesting project. Do the task inputs and outputs change frequently, preventing the use of a simple dependency graph? Can you say more about the business domain? If you haven’t seen this, you may find it useful for working with pull expressions: https://github.com/edn-query-language/eql
@UCHV4JZ7A the problem with a hand-coded dependency graph is that the tasks are sort of "locally owned" by different teams. This project coordinates tasks across the org.
@U0ECYL0ET are you familiar with terraform at all? would you say your tool is similar?
I am familiar, we use it. I have big rants on terraform. Our thing is much higher level.
Our thing's tasks are like, "we need a marketing site". That integration might use terraform.
There's some similarities, except that we really lean on forward-chaining rules. We need to have things built as early as possible, and we incrementally discover the information we need to do things.
I want to write a terraform like thing in clojure. So I may look closer at what you're saying here.
@U09LZR36F Pulumi uses Terraform under the hood (and therefore takes advantage of the existing Terraform ecosystem), perhaps adapting Pulumi to Clojure would be a reasonable route to take https://github.com/pulumi/pulumi, https://github.com/pulumi/pulumi-terraform
@U0ECYL0ET we probably share complaints about terraform, and also the level at which you are describing things sounds similar to a project I tried to tackle things.
My main complaint is that it is trying to be declarative. I think that's a mistake in that domain. We frequently need one object per thing in some database, for example, and that leads to terrible duplication and weird text ETL procedures.
Those ETL procedures defeat the idea of what terraform is for. So they've added things like loops and getting external data, but it is kind of terrible and they don't want you to use it.
Oh I know. And the modules don't even help! Count doesn't even work for the "loop construct" in a number of cases, so you have to take explicit counts for everything
The terraform language sucks, generally. I'd love it if they had a minimal extensible core.
In Clojure, terraform really just becomes a data structure and a plan/apply procedure. The data structure can be generated by a function.
The data structure needs some kind of ?var to bind results of some operations to inputs of others. Unlike the go people, we know about proper unification :D
So, I'm looking at clara to do the dependency graph of work semi-automatically. For example, when do you go fetch the list of GitHub users? Well, if something wants to query them (and then you cache it). If you've diffed the list of users, and something inserts a new user, then you need to change your actions based on that. This is a pretty half-baked idea though 🙂
So, are you using it ahead-of-time to build a plan? Or are you using it during execution?
thinking about trade-offs, I decided that a plan is possible to do as an auxiliary based on a secondary set of rules which inform you of the "optimistic write output" of a task.
We're thinking about depending on clara_eav, since this will need a triplet type, and I'm considering the EAV record in clara_eav the "canonical triplet type" for Clara.