Hi, I am dealing with some state in my library where I find myself doing (swap!) on two or more atoms sequentially, as they represent a different kind of state, but sometimes I have operations that change more than one at same time. Don’t need multi-threading, just 1 thread can handle them. So I think, maybe all of this should be just 1 atom with nested maps. Is it fine / recommended to have atoms with big nested maps, over having smaller maps distributed through different atoms? Is there any “general” rule when facing this kind of situations? Thanks!

Hey all, I just started reading about Data Oriented Design. Would people say that this aligns to the goals, or thought processes, of Clojure? I have seen that people are encouraged to think of data while working with Clojure, but, while reading through Data Oriented Design articles, I can't immediately tell if these are the same things. Example talk https://www.youtube.com/watch?v=rX0ItVEVjHc

so maybe kind of a silly question, but I'm curious... what is the actual difference between using .toLowerCase vs using clojure.string/lower-case?

the latter is a wrapper for the former

I figured that ... so in that case.. why use the latter at all rather than just use the Java class directly?

the latter is more general and clojury, it calls toString on its argument first

so would you say that in a Clojure environment... using the latter would be safer?

I would say its more idiomatic

the clojure one will work with anything that has a toString method

ah gotcha.. thanks! As minor as a thing like that seems to be, I'm just trying to figure out the reasoning behind decisions to use what and when.

use the clojure one since its already type hinted

normally, if the clojure std lib has a function for a java method use the clojure one

that's fair. Thank you!

Also, the Clojure one is portable to Clojurescript

@ryan.russell011 also you can treat lower-case as a first class function, which is not possible with .toLowerCase:

(map string/lower-case ["Alice" "Bob"])

(map #(.toLowerCase %) ["Alice" "Bob"])

ah.. also a good point.. wasn't thinking about that aspect

Hi I'd like an under the radar clojure function that is very useful to you

juxt is underrated

and fnil

some->

oo could you tell me about juxt?

fnil i have found very useful for the case where i'm conj'ing into a #{set}

juxt takes N functions and returns a function calls each function on its args and puts them in a vector

user=> ((juxt - * / +) 42 3)
[39 126 14 45]

user=> ((juxt - * / + > <) 42 3 1)
[38 126 14 46 true false]

wow

Awesome

easier to reason about when i think of it as applying the function to the params in columns

right, each function you give it generates a column, calling the resulting function gives you a row

that's very interesting. one could store a lot of information in juxt result vectors ... with meaningful juxt fns

I am confused by

yup that's a classic use for juxt

(from http://clojuredocs.org/juxt)

oh wow

the first col is the result of take 3

and the second the result of drop 3

sneaky.

i would like to make a reference one day of clojure phrase synonyms

sometimes there are many ways to achieve the same effect

so juxt can be a million fns

i'm trying to stretch my imagination since sometimes i assume limits where there are none! xD

@sova here's a macro that's very useful when debugging

(defmacro locals
  []
  (into {}
        (map (juxt (comp keyword name)
                   identity))
        (keys &env)))

(speaking of juxt)

okay, looks cool. spits out a list of local vars?

ledger.balance-loader.unit-tests=> (defn foo [x] (let [y (+ x x)] (println (locals)) y))
#'ledger.balance-loader.unit-tests/foo
ledger.balance-loader.unit-tests=> (foo 2)
{:x 2, :y 4}
4

magic!

wow cool

very useful for debugging for obvious reasons

one of the rare macros that has no use or need for quoting as well

noisesmith, you just made my day

thank you again kind fellow, that is so sweet

can you explain to me why i only need to call (locals) within a fn and not pass it anything? like... i get that they share scope but i don't understand how exactly

scope is nested - you can see surrounding context from a macro, through the implicit &env binding

(it's actually an invisible arg passed into the macro by the compiler)

there's also a &form binding which gives you the raw form which the macro saw before running

wow, cool! &env and &form

i feel like i'm looking inside clojure's brain

are there any others than &env and &form?

btw https://www.youtube.com/channel/UCH0CkLvbv6yEyrUnw9qujpQ/videos

thank you @victor.cleja

Enjoy ;- )

And, yes, juxt is pretty cool

ledger.balance-loader.unit-tests=> (defmacro wizardry! [& whatever] (prn ((juxt type (partial map type) identity) &form)))
#'ledger.balance-loader.unit-tests/wizardry!
ledger.balance-loader.unit-tests=> (wizardry! 1 2 3)
[clojure.lang.PersistentList (clojure.lang.Symbol java.lang.Long java.lang.Long java.lang.Long) (wizardry! 1 2 3)]
nil

it's fun trivia, maybe not apropriate #beginners material

damn so cool. the symbols

no it's perfect, i'm trying to expand my knowledge on the whole #!

so clojure.lang.Symbol and stuff, the compiler uses these to arrange everything properly and through some magic makes computations happen?

notice I used juxt again there

I asked it for the type of &form - list

then (partial map type) - you know what that would return, right?

so what that's showing is that &form contains a list of the values in the macro call before anything is done to them, including the macro symbol itself

quick question, is it correct to say (partial map form) is a transducer?

oh i see. juxt and partial play together nicely

super sweet!

no, (partial map f) is a function, that takes 1 or more collections and maps f over them

if you called it with no args, it would return a transducer

and the transducer would map f over its input (of whatever sort that might be)

I have a vector like this: [1 2 3 4 5 6] and I want to turn the first two indices into a nested vector [[ 1 2] 3 4 5 6] -> my solutions have all a little too clunky. For example:

(into (vector ((juxt first second) [1 2 3 4 5 6])) (drop 2 [1 2 3 4 5 6]))

=> (apply into ((juxt (comp vector (partial take 2)) (partial drop 2)) [1 2 3 4 5 6]))
[(1 2) 3 4 5 6]

this is a case where likely the right solution is to use a simple let block, instead of funky higher order fixed point functions

That's good to know, I figured that because I want to consistently do this to this particular piece of data that it might be best to figure out something "functional". Good to know

a let block is still functional, it just trades the elegance of anonymous application for the clarity of separating steps explicitly

how about this? @tkjone

=> (apply vector (vec (take 2 v)) (drop 2 v))
[[1 2] 3 4 5 6]

Yep! Thats certainly much nicer than mine

(vec (take 2 v)) can be replaced with (subvec v 0 2)

if you know v is guaranteed to be a vector, yes

right

there might be some trickery you can do with (split-at 2 v)

=> (reduce conj (split-at 2 v))
((3 4 5 6) 1 2)

haha

=> (reduce conj (rseq (split-at 2 v)))
((1 2) 3 4 5 6)

first time the 2-arity version of reduce has come in useful 😁