https://www.youtube.com/watch?v=p3Rb7uxtQs4

I haven't used JMX Explorer in particular, but it should be possible. I've used VisualVM and other profiling tools to help tune memory usage and performance. (Everything in this vein I've learned from http://clojure-goes-fast.com/blog/)

(first (keep-indexed #(when (= id (:id %2)) %1) d))

(reset! array-of-ticked (update @array-of-ticked index (fn [e] (assoc e :ticked %)))) This is what I do currently, update by index. I wanna update by :id. How exactly?

i do not understand your question/code

I want to reset array-of-ticked, make :ticked be true, where :id = 1993 for example

(map #(if (= 1993 (:id %)) (assoc % :ticked true) %) @array-of-ticked)

Rather than storing the data in an array (and updating by index), I would store the data in a hash map indexed by id. That would make modifying the data structure much simpler. It would look like:

(swap! ticked update-in [id :ticked] not)

yeah i would do the same.

Ok, so after switiching to hash-map, how exactly do I write it? This is what I had before since its a reagent:

(reset! array-of-ticked (update @array-of-ticked index (fn [e]                                                                                                                                              (assoc e :ticked %))))

Rather than your atom being an array, it could be a hash-map like below. You could update it using swap!. Here's some examples of what the atom would be:

(def ticked {})
@ticked ;; {}

(swap! ticked update 1993 not)
@ticked ;; {1993 true}

(swap! ticked update 1993 not)
@ticked ;; {1993 false}

(swap! ticked update 1541 not)
@ticked ;; {1993 false 1541 true}

https://clojure.github.io/clojure/clojure.set-api.html#clojure.set/map-invert

lol I just wrote

(defn swap-map [m] (reduce-kv (fn [m k v] (assoc m v k)) {} m))

you are!

There is 0 shame (and perhaps some reason for pride) to reimplement functions in Clojure core 🙂

I looked at the map-invert source code, and it's essentially the same as Benjamin's version, but uses persistent! and transient. What's up with that?

It’s faster

The whole point of transients is to improve performance when bulk loading a collection

Functions like into or reduce are doing that for you so usually you’re getting that without knowing it

I don't want to hijack the clojureverse discussion, but I want to say that this is really generous of you! And this might actually be a way to collectively help with clojure adoption.

Thanks @U3X7174KS. TBD if it anybody bites.

I think you've got a good perspective on the double-edged sword of macros. My philosophy is: "don't use macros unless you must use macros". In practice, I've rarely had to write macros within an application (4 times in 10 years?), and mostly have written macros for sugaring the APIs of some library-like things. As a beginner Clojurian, I wouldn't even worry about writing macros at all. Being able to recognize and use special forms / macros in the standard library and other libraries is sufficient for a long time.

@U0CLNM0N6 this sort of confirms my instincts -- it's nifty but maybe dangerous and the standard library is extremely powerful. Maybe I'll leave metaprogramming alone for the time being.

Macros are nifty and powerful, and I'm very glad they're in the language (to allow for libraries like clojure.async), but, not necessary for most day-to-day needs. IMO, they definitely don't need to be on a beginners "must learn" list.

Totally agree with the other comments. Despite being fairly inexperienced with clojure, I have used macros a few times to improve code clarity. One that springs to mind is a macro to execute the body in a try catch, log any error that occurs and return nil. It was cropping up multiple times in the problem I was solving and it reduced some visual clutter from the code. It wasn’t a production codebase and there could have been (probably were) better ways to solve the problem, but it helped me at the time and I think it’s okay to dip your toe in the water just to get a feel for it

I would not say they are dangerous. But I think a fair philosophy of preference is: data >> function >> macro and these are not mutually exclusive

if you can represent your problem as data and use the standard api of data manipulation to solve it, that is always a good base. if you need functions that give you better tools to manipulate that data, do so. if you then want custom language, then by all means - that's what macros are for (but you still probably want to have those macros assemble function calls that transform data)

reach for macros when you want a custom language to talk about your problem, or a refinement of existing macros (for control flow in particular), or for advanced forms of DRY

The most annoying issue to run into with macros is basically custom versions of def. People write macros that do some kind of cool neat thing, make the macro also def a global name

In your learning journey I'm sure you'll come across clojure spec (https://clojure.org/guides/spec). Contrasting that library whose user-facing API is all macros, with malli (https://github.com/metosin/malli) whose use-facing API is all data and functions should help solidify the tradeoffs between the two. For example let's say you have a spec describing a hashmap that must contain a certain set of keys. If you want to define a new spec based on that spec (like adding a new required key) you must do some really annoying things because you're dealing with a macro. To do the same thing with malli you can use conj because you're dealing with data.

@U051V5LLP Which is why https://github.com/clojure/spec-alpha2 supports full programmatic construction of Specs (and even has specs-as-data as a layer in there)...

(it just isn't "cooked" yet)

My two cents on when to use macros: you need to delay the evaluation of some expression. Examples: all the control structures (if, let, etc.), with-open (and other with-*).

There is also a continuum between other code generation approaches and macros and homoiconicity makes all of them easier. It is easy to generate clojure code and spit it to a file because it is all clojure data structures and clojure.core provides all kinds of functions for manipulating those

Clojure being a Lisp-1, macros are not as big a deal as in Common Lisp, because macros hide boilerplate and Lisp-1 eliminates the boilerplate of using anonymous functions. That said, macros are neither dangerous nor to be avoided until some point in time/experience with Clojure; use them to hide boilerplate. Lisps are intoxicating; you may be inventing a new Web DSL in a few days and want macros badly. As for macros confusing codebases, HLL mechanisms do not generate confusion, they magnify their users' confusion, commensurately with the mechanism power. But we Lisp for power. Good programmers can safely embrace more powerful mechanisms...how did I segue into dragging Java? :rolling_on_the_floor_laughing:

The function name needs to be fully qualified, ie. level-12/comment-count-str (they've whitelisted it for you already).

Aha! Now I see how the namespaces are declared and used — thanks so much!