Just realized they are not the same. But works for my use case, so still pleased 🙂

(remove (comp true? :SKIP) maps)

It was at exactly the moment when I made such a discovery (while drooling on The Joy Of Clojure in the bay window of a shawarma shop) that I fell off the stool laughing and was hooked.

two potential short answers - re-list them or quote the list:

(defn do-smth [sequence] sequence)
(defmacro first1 [& args]
  `(do-smth '~args))
(defmacro first2 [& args]
  `(do-smth (list ~@args)))
(first1 1 2 3)
;=> (1 2 3)
(first2 1 2 3)
;=> (1 2 3)

(first1 5 6 (+ 1 2))
;=> (5 6 (+ 1 2))
(first2 5 6 (+ 1 2))
;=> (5 6 3)

Will this do what you need? (defmacro first [& args] `(do-smth [~@agrs]))

I guess I could just shove the values into a vec, and then use them after

(let [ch (a/map vector [(a/go 1) (a/go 2)])
      [x y] (a/<!! ch)]
  (throw (Exception. "Fail"))
  (+ x y))

there isn't since almost everything is constant (immutable), you would probably end up with everything in upper case. I have seen it the other way around, some naming conventions for refs, like *my-ref

every def is a constant

feel free to make your own conventions though of course. that’s how things become conventions in the wild. people try something and others like it

i tend to see ALL-CAPS as a way to denote global vars that should be considered "constants"

Thanks team!

I’ve been working on exactly that recently. I have something like this:

(def ^:dynamic *span* nil)

(defn new-span
  [span-name]
  (when @tracer
    (-> @tracer
        (.spanBuilder (name span-name))
        (cond->
          *span* (.setParent (-> (Context/current)
                                 (.with *span*)))
          (not *span*) .setNoParent)
        .startSpan)))

(defn end-span
  []
  (when *span*
    (.end *span*)))

(defmacro span
  [span-name & body]
  `(binding [*span* (new-span ~span-name)]
     (try
       (do ~@body)
       (catch Throwable t#
         (.recordException *span* t#)
         (throw t#))
       (finally
         (end-span)))))

Love this! Thank you @U0DTSCAUU

write less dense functions

my function looks as dense as many of the library functions I've been reading so I imagined there was some kind of workflow/method for this

if your function is defined in code and required you’ll have better line information. write your code in a source buffer, (require <the-namespace> :reload) to reload the code, and then call it and you should have stack traces with line numbers on them so you know where the error is occurring

if it is too dense for you to debug effectively, it is too dense

but in general, his advice is solid. It’s fun to codegolf and feel clever. But it gets quite tedious to try to figure out where it goes wrong. Writing less clever code can greatly ease in debugging

@U11BV7MTK that worked! Thanks! I say "dense" with a relative context - dense for me (a beginner). It's function with a let, a filter and then a let inside that filter which ought to be simple enough. I've seen denser functions in clojuredocs

i have a hotkey to (require <current-namespace> :reload) and use that almost exclusively. if you eval things individually there are no line numbers so you’re left guessing

same with source, doc, and other niceities

Hmmm interesting. Do you know why that's so? I would have thought evaluating functions as I go wouldn't be any different

as an alternative for consideration, Stuart Halloway has talked about an example that might be useful: <https://vimeo.com/223309989#t=1790s>

the repl can’t really track line numbers. if you enter (+ 1 1) that’s just kinda line 1 right? So evaling stuff can’t really have line numbers. When you require a namespace, it goes to the file that specifies it and it keeps track of line numbers as it goes through each form in the file

i sent the divide-and-throw function to the repl. and the line number is REPL:189 which isn’t super helpful

core=> (defn divide-and-throw [x]
         (/ x 0))
#'metabase.automagic-dashboards.core/divide-and-throw
core=> (divide-and-throw 3)
Execution error (ArithmeticException) at metabase.automagic-dashboards.core/divide-and-throw (REPL:189).
Divide by zero

core=> (divide-and-throw 3)
Execution error (ArithmeticException) at metabase.automagic-dashboards.core/divide-and-throw (core.clj:1724).
Divide by zero

That makes a lot of sense, thanks again! Would have been completely in the dark since I simply didn't have the line number

👍

Following up on this advice, I don't ever type into a REPL. I put scratch code in a file - usually in a (comment ...) form and use my editor integration to eval it. If you can get used to a workflow like that, you'll find working with Clojure becomes a lot easier.

That's typically what I do, and it's a fantastic experience. I was so used to just evaluating things like that, I never considered reloading namespaces instead of just evaluating functions. I've definitely hit the line numbers problem, and never realized there's such a simple solution. Live coding just got a level up 🙂

yeah. people might not realize that evaluating the form without typing it into the repl actually sends it to the repl

I feel like I knew that's how it worked, but somehow it never really clicked that line numbers are a consequences of loading a namespace and so you wouldn't get them by piecewise building up a namespace by sending forms to the repl

Thanks for spelling that out 👍:skin-tone-2:

@U05N8AJMWQG shameless plug here, but have you seen http://www.flow-storm.org/ ? If I type some contrived one liner like this :

user=> (let [coll [0 "1"] v [:first :second] a (let [b (->> coll (map (fn [n] (v n))))] b)] a)
...
Error printing return value (IllegalArgumentException) at clojure.lang.APersistentVector/null (APersistentVector.java:297).
Key must be integer

I have not seen FlowStorm, it looks insanely powerful. I'll check it out!

OP mentioned filter & unilluminating *e. That combination can result from lazy sequences. A debugging technique is to wrap a suspect (filter...), (map...), etc., in (doall...) to force the whole sequence to be realized then-and-there.

Or use filterv and mapv (eager, producing vectors).