This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-23
Channels
- # aleph (1)
- # architecture (4)
- # aws (7)
- # beginners (249)
- # boot (17)
- # calva (4)
- # cider (30)
- # cljdoc (7)
- # cljs-dev (1)
- # cljs-experience (3)
- # clojure (69)
- # clojure-dev (7)
- # clojure-europe (1)
- # clojure-italy (7)
- # clojure-japan (15)
- # clojure-spec (6)
- # clojure-uk (39)
- # clojurescript (51)
- # cursive (31)
- # data-science (4)
- # datavis (1)
- # datomic (40)
- # dirac (67)
- # duct (8)
- # editors (15)
- # emacs (9)
- # events (3)
- # figwheel-main (2)
- # fulcro (157)
- # juxt (4)
- # kaocha (11)
- # lein-figwheel (1)
- # off-topic (31)
- # pathom (18)
- # re-frame (4)
- # reagent (2)
- # reitit (16)
- # remote-jobs (1)
- # shadow-cljs (11)
- # specter (2)
- # speculative (1)
- # tools-deps (27)
- # vim (1)
- # yada (2)
Bore da pawb
Don't forget CfP for Build IT Right conference in Newcastle 4th April closes midnight Friday and early bird tickets stop after 31st January https://bitrconf.org/
Hiho 👋
morning
kibit doesn't like threading macros eh?
(I vaguely remember this discussion already coming up before re: linting)
thread all the things imo
I tend to only use threading macros once I get beyond a fn wrapping the result of one other function but I sometimes like using let
to provide intermediate names when it helps readability.
I think I'd generally start threading at 2 items, but the one I saw was two long function names from a lib, and using the threading macro inlined them
which made it super more readable
(even if the way they were being called was simple)
the other thing the threading macros do is give you some additional info about which argument is the focus, which i find useful for code comprehension - sometimes even with just a single call
I agree 🙂 (I wrote a while back about it https://stackoverflow.com/a/32167270/1327651 )
Threading can make it less obvious when the output structure of each form changes dramatically though. Like if one function outputs a vector and the next takes that in and outputs a map, or even something that takes in a map and outputs another map with completely different keys
We tend to restrict threads to where we are passing in a map and associng/updating/dissocing keys, or similar actions where it is a modification of the same data structure. That is like 90% of what our function do though, so we do tend to thread a lot
ooh I have thoughts... but I need to cycle home before I get killed by ice
I think your pattern is probably pretty good there, but there's something you could do with schemas on reads or types I think (?)
need to think about it more
wish me luck and further life
my eyes frosted up on the cycle in lol
I'd agree theres an assumption that a thread represents a pipeline; I want to be able to comment out one line of the thread and not automatically break the code. which implies that the threaded elements all input/output the same datatypes
@carr0t this is essentially what you said: https://stuartsierra.com/2018/07/06/threading-with-style and I agree
Only thing I disagree with is not mixing ->
and ->>
. I think it’s ok iff you do it over the first arg only e.g
(-> (->> col
(map foo)
(map bar)
(zipmap [:a :b :c])
(assoc :d :e))
Ultimately you’re probably better using a let
but I don’t find the above hard to read.at this very moment I am running 3 test clients to my own MQTT broker and each client is sending and receiving 1M messages.
One thing brokers tend to do is keep a count of the number of messages that have been processed... but just having an atom with a int in it and calling inc
on it doesn't feel right some how (I have heard from other people that you get too many retries if the rate of updates is very fast (and it would be the case here)). Would an agent make sense? I don't mind it being a bit behind after all
@thomas i've successfully used agents when i wanted to update a value from many threads without retries