Have you tried first with just one function?

the compiler exception is weird, your code will not work but it should compile

there are two problems though: 'namespace will not work, you should be passing symbols anyway to your meta-info function so just remove the quote you want vals instead of keys, ns-publics is a mapping symbol -> var and the metadata is attached to the var

A couple of things: • you are quoting the namespace - it should be namespace not 'namespace • you need to get a var, not the symbol

(defn meta-info [namespaces]
  (let [meta-information (for [namespace namespaces
                               :let [all-functions (keys (ns-publics namespace))]]
                           (for [function all-functions
                                 :let [fn-var (ns-resolve namespace function)]]
                             (meta fn-var)))]
    (prn "meta-info!" meta-information)))

Ah, what rolt said is better - so just use vals

(defn meta-info [namespaces]
  (let [meta-information (for [namespace namespaces
                               :let [all-functions (vals (ns-publics namespace))]]
                           (for [fn-var all-functions]
                             (meta fn-var)))]
    (prn "meta-info!" meta-information)))

no, the function call only happen once when you load the namespace, or re-execute whenever you reload the namespace

what if we use some-variable multiple places ?

it doesn’t matter how many times you reference a var, the value “store” in a var at the time of def

ahh i see

Thanks for your respone

(defn foo [{:keys [a]
            :or {a "default"}}]
  (prn a))

Thanks, that's pretty cool

juste beware: if you call (foo {:a nil}) you'll get nil instead of "default"

Follow up question: is there a way to get the default value in the :as bit?

user=> (defn foo [{:keys [a] :or {a "default"} :as m}] m)
#'user/foo
user=> (foo nil)
nil

user=> (defn foo [{:keys [a] :or {a "default"} :as m}] (assoc m :a a))
#'user/foo
user=> (foo {})
{:a "default"}

that's a bit more than destructuring then 😅

Is it? I'd expect it would be possible to have a separate :as-default that provides the original destructuring with the missing default values mixed in

But yeah, my usecase is just a function that takes a map as an argument, destructures stuff, and is able to set default values for missing keys, then pass the whole map further down to other functions

Or, put it a different way, since you're explicitly defining which values you want for the missing keys, what sense does it make to then receive the original map without the default values for the :as result? It seems likely that I'm interested in the default values, right?

destructuring is for binding some local refs to values taken from original data structure. So your code is interested in them (references) rather than original data

usually you should have something like “normalise” to turn the data into desired shape.

Well, yeah.. I'd like to create my normalise by using destructuring and default values, lol

then it would be better to have explicit steps to normalise the data in such function 😉 compare those two functions:

(defn normalise-1 [{:keys [a b]
                    :default {a 1
                              b 2}
                    :as-with-default m}]
  m)

(defn normalise-2 [m]
  (cond-> m
    (not (contains? m :a)) (assoc :a 1)
    (not (contains? m :b)) (assoc :b 2)))

Ah, you're right. The first two bullet points are a solid refutation

(gen/sample your-generator) for instance. There are other functions depending on your needs

this is a nice walkthrough on how to use generators: https://www.youtube.com/watch?v=F4VZPxLZUdA

I did quite a bit of Java before coming to Clojure and I can't say it helped me much when I started. Learning the syntax and semantics of the Clojure language is what I needed to focus on. At this point, I would say that some of my knowledge from Java (really the JVM itself) has helped, but not in any significant way.

It depends on what you are trying to do though!

I guess I'd like to get familiar enough with Java to get a little dangerous with the interop, and maybe get a basic understanding of the JVM.

right, yes! this has taken me pretty far in that respect -> https://clojure.org/reference/java_interop

and re: jvm, this is a succinct little summary -> https://www.geeksforgeeks.org/jvm-works-jvm-architecture/

the class loading stuff is relevant. here is an article from the clojure perspective -> https://danielsz.github.io/blog/2021-05-12T13_24.html

Wonderful!

just remember to have fun, writing lots of small programs is a great way to get started with clojure. babashka scripts are a great and useful way to do that! https://babashka.org/

also, using this for project templates is good and then making sure you understand namespaces and lib imports and how to configure your repl -> https://github.com/seancorfield/clj-new

2-4 stateful components seems like the perfect starting point, definitely worth it IMO

It's hard to say. There are advantages to using one of those frameworks even in a simple system like you've described - easier to switch between dev/prod/etc. environments, easier to provide stubbed services (like for testing), and WAY easier if your system grows in the future. Plus, there's the experience/knowledge you gain from using them. But you can always iterate. If it's bogging you down trying to set up and keeping you from an MVP, then push it to a second- or third-level of application refinement.

Good to hear! I'm in the situation you described (trying to push out an MVP quickly), and hearing that it's not an "absolutely required that you do this pre-launch" is exactly the direction I was looking for--and I'll be excited to factor some of these tools in when I have some more time. Thanks so much!

I've worked on code-bases with over a hundred thousand lines of code, and talked to multiple running systems, like databases, messaging systems and external APIs, without using one of these frameworks and that wasn't a problem. I have also worked on systems that were complicated by the introduction of Component unnecessarily. I think there are several ways you can go to solve the problems that these kind of tools are trying to solve and it's difficult to offer advice about if it's worth it from outside the project. If you really have a problem with your dev workflow, or managing connections in production, for example, I think it's worth being specific about that problem and evaluating the available solutions. If you're working on an MVP, the data you're collecting is probably way more important than the software you're writing and you absolutely should be focusing on the business problems 😉

Appreciate the perspective 🙂. Sometimes it's easy for me to get lost in trying to do everything "best practice".

It's an easy trap to fall into and we've all done it.

it's useful when you start having complex dependencies between your components. That being said, even with 4 components i'd implement a lifecycle protocol/multimethod (not necessarly using those libs, its really 5 lines of code)

Luckily, I'm at the triviality level where components don't really depend on each other. I think I'll go ahead and implement some basic lifecycle behavior across each of them--and maybe just skip the complex injection stuff for now.

this definitively should not happen, are you sure you're not running a big computation in a "def" somewhere ? (def a (expensive-computation)) the expensive computation will be called when you require the namespace that contains "a"

(or even just (expensive-computation) in a namespace)

remember that if you've generated a huge object, it can't get garbage collected until there are no references pointing to it, like vars or the *1/`*2` special vars ... it's these last ones that always catch me out 😉

No, there is no expensive compute as far as I can tell -

;; Helper function to read the CSV data into a map
(defn csv-data->maps [csv-data]
  (map zipmap
       (->> (first csv-data)
            (map keyword)
            repeat)
       (rest csv-data)))

;; Read the CSV data into a map
(defn read-csv [f] (->> (io/reader f)
                   (csv/read-csv)
                   (csv-data->maps)))

(def csv-data (read-csv "in-file.csv"))

the ring spec allows for certain different kinds of things as :body value, but a clojure map isn't one of them, so if you are setting a map as the :body value, and not just getting an error, then you have some middleware or something transforming it

Good to know

my guess would be something calling flatten or using clojure.walk somewhere, but something in your middleware