Clojurians Log v2

I don't actually remember, but probably just avoiding the clojure.main require

this is no longer needed in spec 2

(because things stay symbolic without being eval'ed to a function object)

I’m solving this problem: https://leetcode.com/problems/sort-integers-by-the-power-value/ And the code I have does generate the correct sequences, but it nests them in weird ways, and I can’t figure out how to have all the paths in a vector with no nesting:

(defn dfs [graph i arr n result]
  (if (= i (- n 1))
    (conj result arr)
    (map (fn [j] (dfs graph j (conj arr j) n result)) (nth graph i))))

(defn all-paths-source-target [graph]
  (dfs graph 0 [0] (count graph) []))

(all-paths-source-target [[4 3 1] [3 2 4] [3] [4] []])

Is this the output you’re looking for?

([0 4] [0 3 4] [0 1 3 4] [0 1 2 3 4] [0 1 4])

Not sure if this is the right channel to ask, but I'm wondering about the meaning of "policy" in Rich's talks and on the Clojure website.

Can you provide link(s) to where that is mentioned?

For example here https://clojure.org/reference/metadata. > It is used to convey information to the compiler about types, but can also be used by application developers for many purposes, annotating data sources, policy etc.

And from transcripts, here are Rich’s mentions: https://github.com/matthiasn/talk-transcripts/search?q=policy

My initial reading of those references in his talks is “executable strategy” and that seems to apply with metadata too.

Where he talks about policy in the context of windowing buffers, for example, he’s talking about whether they drop data or block etc. I think if we were in the OOP world, we might talk about the Strategy Pattern in such situations?

The talk I was thinking of was Simple Made Easy - > You should have probably many more subcomponents than you have, so you want really much smaller interfaces than you have, and you want to have more subcomponents than you probably are typically having because usually you have none. And then maybe you have one when you decide, oh, I need to farm out policy. If you go in saying this is a job, and I've done who, what, when, where, why, and I found five components, don't feel bad. That's great. You're winning massively by doing that. You know, split out policy and stuff like that

My reading of that is that he’s talking about splitting out “executable strategies” and not just embedding it into the core function.

That makes sense. I guess in the context of metadata you could include some information about which strategy to use.

Smaller, more focused components are more likely to be reusable, and then you build functionality by combining components in different ways. With metadata, a good example is protocol implementations now, where you can add metadata to an object and have it conform to a specific protocol — so the annotated object carries its “policy” with it, rather than the policy being embedded in some conditional code somewhere (or even directly inside the object itself).

It’s about pulling things apart and then being about to combine them in new ways.

I was wondering if metadata protocols were an example of this. Thanks this is definitely clearer 🙂

datafy and nav are good examples, I think. “how do I turn this object into data?” “how do I navigate through this object (in relation to its representation as data)?”

Those are very contextual but also need to be separate from both the system that invokes datafy/`nav` and from the object implementations too.

So a subcomponent might be a protocol, not a different instance, like the Navigate component of some data.

through context, I've always interpreted "policy" as logic about a cross cutting concern. Some examples • garbage collection strategy: Mark and Sweep, Parallel, etc • when you submit a new job or run a future, do you use a thread pool, which kind, is there back pressure? • access control for a REST api • logging • lock acquisition order • monitoring and instrumentation