This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-21
Channels
- # announcements (4)
- # aws (29)
- # aws-lambda (1)
- # babashka (21)
- # beginners (143)
- # calva (47)
- # cider (31)
- # clj-kondo (24)
- # cljsrn (4)
- # clojure (70)
- # clojure-australia (3)
- # clojure-czech (1)
- # clojure-europe (97)
- # clojure-greece (4)
- # clojure-nl (3)
- # clojure-uk (45)
- # clojurescript (70)
- # code-reviews (1)
- # conjure (7)
- # cursive (10)
- # datomic (13)
- # duct (5)
- # emacs (1)
- # fulcro (38)
- # graalvm (1)
- # graphql (9)
- # honeysql (13)
- # integrant (33)
- # jobs (14)
- # jobs-rus (1)
- # malli (7)
- # off-topic (72)
- # pathom (1)
- # re-frame (11)
- # reitit (9)
- # remote-jobs (2)
- # sci (11)
- # shadow-cljs (9)
- # sql (5)
- # tools-deps (5)
- # xtdb (6)
Lesson being....Don't go to bed after just watching the video by @seancorfield on REPL Driven Development, kiddies!
mawnmån
was your dreamcoding productive though @dharrigan?
It was the most amazing software ever written, that made me richer than our friend Mr. Bezos.
morning
Morning
Hmm, not used tap>
much myself, not really figured out how to fit it into my workflow, does seancorfield's REPL driven development video showcase it?
I use #dbg
etc in emacs a lot, not sure if that's similar or not
s'a cider feature
I personally much prefer scope capture to using tap>
I should add I don’t typically use a sidecar tool like Sean; e.g. reveal, rebl, portal etc… cider has a lot of that functionality already.
So if you’re using those tools you may need the tap>
to render the value in them anyway.
Regardless scope capture is awesome; you can essentially capture a scope and jump your repl into the scope to debug etc… So unlike tap>
you capture all the values in lexical scope.
It’s not like a step through debugger because you’re not jumping into the stack; everything already happened, and the stack will have unwound. But I find it works better; it’s much less mechanical and a more functional way of debugging
though you can use it for much more than debugging
remove takes a predicate, right? so shouldn't it be (remove nil? [1 2 nil nil 3])
or can it take a set too?
because (#{nil} nil) => nil)
- it looks up the nil
from the set, and you get the looked-up value back, which is nil
doh, that's wrong - it's like a fn
which looks up its arg with get
ahh of course
what are the upsides of doing it that way?
(remove nil?)
is straightforward comin' atcha bit of code
(filter identity)
seems like it is trying to conceal its real intentions
no doubt for some nefarious purpose