(fib-seq-iterate (fn [x] x) 0) throws an exception when I try it, but fib-seq-iterate generates a sequence of fibonacci numbers:

fib> (take 10 fib-seq-iterate)
(0 1 1 2 3 5 8 13 21 34)

fib-seq-iterate has at least 3 parts: 1. iterate 2. the function passed to iterate, (fn [[a b]] [b (+ a b)]) 3. (map first ..) Do any of those pieces makes sense? Is there a particular part that is more confusing?

nah I get the take 10 thing, just was confused with somebody passing it a function

probably just a broken example then

1. Not working in the REPL, not referring to cheatsheet, not using apropos and find doc, using a debugger instead of an inspector 2. More is better. See if you can find excuses to use it for scripts at work (also see babashka) 3. I like 4clojure and the koans. Also, the official docs are great 4. Depends on what you find effective 5. Imperative thinking, code organization, finding resources and putting libraries together correctly

As a perpetual learner myself, I’m interested about the question about debugger vs. inspector, as I often find myself wishing I had Cider’s debugger at hand. Why would you say the use of an inspector ought to be favoured and if possible do you know if good resources or discussion about the topic exist.

It's not that I don't use CIDER's debugger as a last resort, but my general methodology for "what's going on/what went wrong" is smaller functions and sticking taps in things. Especially when you get to an asynchronous context

By taps do you mean deffing/printing or something else? EDIT: Seems the clojure website aggregates many resources on the subject https://clojure.org/guides/repl/enhancing_your_repl_workflow. I’ve also heard about https://github.com/djblue/portal , which seems to provide “tapping”.

a learning path you find fun is the right one. I like puzzles, so http://adventofcode.com for me.

@U02CC5T8LLU taps, e.g. tap> is the solution to print or inline defs. They send everything to all sinks. Powerful stuff

Portal is a sink for taps. There's also reveal

Another question: How do I break a programming problem down, especially if I know very little? How do I read it? What keywords do I need to look out for? How do I not get lost/get frustrated/feel stupid before even typing defn?

output.calva-repl

Besides the encoding issue it seems that your test treats the body hash-map as a string, but your response returns it as an actual hash-map. Or am I mistaken?

Does it look OK if you use curl on the endpoint?

yes curl return garbage characters too

How can I set charset "Start project nREPL and connect Jack-in"

The problem seems to be that the endpoint returns something else than utf-8. When it looks right in Curl it will look right in Calva, I think.

Also, if the issue was with Calva, the "expected" data should also have encoding issues

I use clojure -M:run the result is ok. In edn config file

:run {:main-opts ["-m" "app.main"]
        :jvm-opts ["-Dfile.encoding=UTF-8"] 

I add :jvm-opts ["-Dfile.encoding=UTF-8"]] to my edn file that is ok!

Not sure if that means you've solved it, @U025AG2H55F, but in case not. I think adding a :dev alias something like this might solve it:

:dev {:jvm-opts ["-Dfile.encoding=UTF-8"]}

yes. you're right! @U0ETXRFEW

In Python this would look something like:

class Reader:
    def __init__(self, exts, ctx_fn):
        self.exts = exts
        self.ctx_fn = ctx_fn

    def read_file(self, path):
        ...  # uses exts and ctx_fn

    def read_directory(self, path):
        ...  # also uses exts and ctx_fn

(defn read-file [path exts ctx-fn] ...)
(defn read-directory [path exts ctx-fn] ...)

The amount of shared parameters could be even bigger perhaps, but even in this example it feels cumbersome to have to passs these around explicitly. Can someone help me undo my OOP thinking? And/or explain how to deal with this?

I think you can do that with https://clojure.org/reference/protocols and https://clojure.org/reference/datatypes:

(defprotocol AbstractReader
  (read-file [this path])
  (read-directory [this path]))

(defrecord Reader [exts ctx-fn]
  AbstractReader
  (read-file [{:keys [exts ctx-fn]} path]
    (prn exts ctx-fn path))
  (read-directory [{:keys [exts ctx-fn]} path]
    (prn exts ctx-fn path)))

(let [my-reader (->Reader 5 5)]
  (read-file my-reader "path")
  (read-directory my-reader "path"))

That looks like a very good fit indeed 🙂. I haven't yet looked into protocols and records, but certainly will. I am still interested to know though: before protocols were added (and in FP languages that lack them), do you know how people would deal with these pattens?

As seamlessly fitting your suggestion is, my guts tell me there's chance to learn more about the FP way of thinking here

Some alternative approaches: You can also just keep the raw defn approach. If you translate your (python?) example directly, then you can close over the exts and ctx-fn :

(defn reader-for [exts ctx-fn]
    {:read-file (fn [path]
                  ;; exts and ctx-fn
                  )
     :read-dir (fn [path]
                 ;; exts and ctx-fn
                 )})

(defmulti reader
    (fn [path]
      (.isFile (io/file path))))
  
  (defmethod reader true
    [args]
    (println "is a file"))
  
  (defmethod reader false
    [args]
    (println "is a dir"))

(untested code but you get the drift)

In any case: whenever you want to translate “this” or “self” to Clojure, you can think of it as “the first argument to my functions is a map with all the stuff in it”

Thanks for those suggestions. They look like really valuable alternatives!

Could you use a function with multiple arities? Like this:

(defn word-repeater
  ([word] (word-repeater word 5))
  ([word times] (repeat times (str word))))

(word-repeater "hello" 3)
;; => ("hello" "hello" "hello")

(word-repeater "hello")
;; => ("hello" "hello" "hello" "hello" "hello")

(defn word-repeater [times]
  #(repeat times (str %)))

((word-repeater 3) "hello")
;; => ("hello" "hello" "hello")

((word-repeater 5) "hello")
;; => ("hello" "hello" "hello" "hello" "hello")

Never mind, after re-reading your question, I realized that my suggestions are irrelevant to your problem. I didn’t think well and answered the wrong questions. 😅

No problem, still interesting stuff that relates in a way :thumbsup:, thanks

be careful using records to translate OO, this can lead to bad (unidiomatic, hard to maintain / read / reason about) clojure code. the normal solution to your initial example is a hash map:

{:path ...
 :exts [... ... ...]
 :ctx-fn ...}

note that even the python example doesn't "get rid" of the repeated params per se, it just bundles them into one object, which is what the hash map does too

Yeah I am trying to be careful with "translations" from OO patterns, so I'm happy with your suggestion. Thanks!

(defn update-list [l new-item] (map (fn [x] (if (= (:id x) (:id new-item)) new-item x)) l))

A map (a data structure) is what you probably need.

If you access your list like this often then a map would be more ergonomic and faster (for sufficiently large collections and regular access) where you map from :id to items in your collection (don’t worry about :id being both the key and a value inside your map, that’s just indexing). But if you’re using a vec or list then mapping over it is exactly what you would do to update a specific item. In other words: Your code is fine.

Do you have an example of a list and an item? What do they look like? (and how would you expect the function to work) Judging from update-list, l is a list (collection, to be more accurate) of maps and each map might contain an :id key? :thinking_face: Your code seems to break down for items that aren't maps (or don't contain :id):

(update-list '(:a :b :c :d) :e)
;; => (:e :e :e :e)

(update-list '({:a 1 :b 2} {:c 3 :d 4} {:e 5 :f 6} {:g 7 :h 8}) {:i 9})
;; => ({:i 9} {:i 9} {:i 9} {:i 9})

For this case it is indeed a list of maps, the predicate function here is mostly for demonstration purposes. As the order in the list is important, I did not want to use a map keyed to ids. (and then have to do extra sorting).

two data structures? ordering and map?

so

{:order '(:a :b :c :d)
 :data {:a {}
        :b {}
        :c {}}}

.No, an ordered list of maps. The key also needs to be part of the map

Alright... Assuming this is an accurate description of the problem: "Given a list of things l, a 2-arity predicate function f and a thing x, how can I replace all items in l that satisfy f with x?" and trying to keep things as generic as possible, you can separate the predicate function (e.g. (defn pred-fn [old new] (> (:id old) (:id new)))) from the mapping function: (defn update-list [l f x] (map (fn [i] (if (f i x) x i)) l)) Glued together:

user> (update-list '({:id 1} {:id 2} {:id 3} {:id 15}) pred-fn {:id 7})
;; => ({:id 1} {:id 2} {:id 3} {:id 7})

;; or

user> (update-list '({:id 1} {:id 2} {:id 3} {:id 15}) (fn [old new] (> (:id old 0) (:id new 0))) {:no-id 7})
;; => ({:no-id 7} {:no-id 7} {:no-id 7} {:no-id 7})

Using lazy operations on a sequence to do a single update is a bad idea. I don't know what your actual domain needs are, but using a list for data that you look up by key is a sign you need a different data design.

what @U3JH98J4R suggested could be an intermediate representation, especially if you find yourself doing multiple updates by id, doing that transform once, then doing the updates, then translating back to the original structure is often a good idea.

It is possible, for example clj-http library conditionally requires the cheshire library. But if the library is pure and doesn't change any external state when required in 90% cases it doesn't make much sense imho

I’ll take a look thanks! My use case is building packages for different builds, where test-builds use some libraries which should not be included in the production build.

https://github.com/dakrone/clj-http/blob/3.x/src/clj_http/client.clj#L21 Here you can find an example

Looks like this does the trick. Thanks again

If you need a library only for tests then i would make separate build processes. You can separate the code that depends on a lib from your core application by splitting source paths.

I will keep this in mind when starting afresh with a project in the future. Do you have in mind some projects or libraries with the structure you described for “getting inspired”?

Nothing that i can share unfortunately.

Yes, I believe this is what they recommend. They're simply suggesting to wrap getters as functions around your config.

You'd probably have something like:

(defn get-current-profile
  []
  (keyword
    (or (System/getProperty "APP_PROFILE")
        (System/getenv "APP_PROFILE")
        "dev"))

(defn config [profile]
  (aero/read-config "resource/config.edn" {:profile profile}))

(defn webserver-port [config]
  (get-in config [:webserver :port]))

(def config (delay (config (get-current-profile)))


;; somewhere else where you use it
(webserver-port @config)

Thank you very much!

there can be, but I wouldn't worry about it unless performance tuning something in a hot loop

it depends a bit what the source is, and whether you want to also apply transducers (which you can with into but not with vec), etc

ah ok, that’s good to know about transducers, in my current case it won’t matter then, thanks!

I consider them both fast :)

You can also use filterv instead, it'll return a vector directly