Cool. I’ve asked for those to be linked up in the relevant places. https://github.com/zk/clojuredocs/issues/207

Also, if you want to answer this publicly, you can here: https://stackoverflow.com/questions/59515087/specifying-bindings-syntax-with-as

it's literally the same syntax and rules as let, and mostly the same as function args - this is intentional

may this help you https://luminusweb.com/docs/guestbook.html

I learned a lot reading through https://pragprog.com/book/vmclojeco/clojure-applied.

Thanks for the book suggestion. My office provides subscription to Oreilly. Will check there.

A caveat on Clojure Applied: Alex has said that if he was writing the book today, it would use records a lot less. So bear in mind when reading it that you should probably use plain old hash maps in many places where the book encourages records.

Hi Sean, do you also know what changed between the time of writing the book and now?

Best practices in Clojure evolve over time 🙂

That book was written 4-5 years ago. Even with Clojure's stability as a language, that's still a long time in terms of best practices.

I think Alex said one of the main differences in "best practices" is around Spec but I can't find his exact comment right now.

April 25th, 2019, in #clojure-spec "Slack: alexmiller: fwiw, I would probably de-emphasize records in a 2nd ed of Clojure Applied" -- still looking for reasoning but that was in response to a comment about modeling the domain using records instead of maps.

Thanks and if I may ask one more question. Is there anything like the AOSA book for Clojure? It need not be a book. Mayne articles, case studies. http://aosabook.org/en/index.html

Since that's an architecture book, I'd expect quite a bit of it to apply to Clojure (although I suspect a heavy OOP slant in that book? I've never read it, nor even heard about it before now)

Maybe search for "domain-driven design clojure" and see what turns up -- since Clojure is about focusing on the data in your domain.

(and you may ask as many questions as you want! 🙂 )

I have found this book: https://leanpub.com/building-a-system-in-clojure. Alas, it's not free.

It started out as a series of blog posts https://matthiasnehlsen.com/blog/2014/09/24/Building-Systems-in-Clojure-1/ and those are free. Also note that the book is only half complete and last updated three and a half years ago so...

Given that it uses top-level defs with side-effecting code (reading a config file, building a Component system), I would be very cautious about treating it as any sort of "best practice"...

Thanks for the input. Appreciate it.

A map is a map. A record is closer to a Java class and the getters are actually offsets into the array like data store of the class.

ahh ok, Thanks for the answer. I was trying to locate this in the source code

Hey, but I am not a full 100% sure. Let me dig up more info.

Okay, let me rephrase that. defrecord creates an actual Java class under the hood.

But still you want to stick with hash maps in nearly all cases. Records are great when you a) always have a small fixed set of keys that you know will always be present and b) more importantly, you want fast dispatch by type, i.e., polymorphism. So don't think of records as "fast maps" -- there are a bunch of trade offs around the choice.

In the second case your arguments are in the wrong order.

You probably want to use ->> instead of ->

to be explicit, with the thread first, you end up with (map coll function) rather than (map function coll). The error is saying it doesn't know how to create a seq from a function.

since your function is where the collection normally goes, map is trying to get it into a seq so it can map over it and has no idea how to turn #(Integer/parseInt %) into a seq

Oh, I see! Thread-first vs Thread-last. Thank you!

sorry @U0NCTKEV8 but I didn’t understant very well. My ref is constantly changing cause user can include new accounts and transactions inside the accounts. Even though could I use like your example?

I forget the exact syntax because I never use refs but with a map instead of a vector for accounts you would do something like (dosync (alter! accounts update-in [account-id :transactions] conj new-tx)) to add a new transaction

Also, I dunno what the rest of you code is doing, but if you only have one mutable reference you can just use an atom, refs are only useful when you need to coordinate changes to multiple mutable references at once, which most people don't end up doing

And what I said about normalization, you may not think of it those way, but what you are creating is an in memory database, so all the database techniques and ideas (indexing, normalization, etc) apply

In your case you have a vector which is equivalent to an auto incrementing key and that is the only index

So you can only look things up quickly based on the position in the vector

But the shape of your data suggestions you need to look things up by account id, which a map will let you do

Normalization in database terms is basically the process of pulling apart and flattening your data model until all of it can be easily indexed for efficient retrieval

Like, what if you just have a transaction id and want to find the account for it

With your model you need to scan all transactions in all accounts to find it (full table scan in DB land)

In a more normalized schema transactions wouldn't be part of accounts, but would be their own thing with there own index on their ids

Then to make looking up the transactions for account fast each tx is also indexed by the account they belong to

I see… so I could actually have something like this so it would be easier to look into the data I want?

(def accounts (ref {"745286b0-24d3-4b17-ab24-d1265e9fb8d1" {:identification_id "33333333333" :name "Account1" :transactions [{:amount 1000.00M :created_at "2019-12-27"}]}
                    "234de110-ec07-4568-884c-8aad330c24eb" {:identification_id "44444444444" :name "Account2" :transactions [{:amount 1500.00M :created_at "2019-12-26"}]}
                    "e1255330-0f63-42cd-b7c8-acde1915f885" {:identification_id "55555555555" :name "Account3" :transactions [{:amount 2000.00M :created_at "2019-12-25"}]}}))

Yes, you can also duplicate the uuid if you want it returned on lookup:

(def accounts (ref {"745286b0-24d3-4b17-ab24-d1265e9fb8d1" {:uuid_account "745286b0-24d3-4b17-ab24-d1265e9fb8d1":identification_id "33333333333" :name "Account1" :transactions [{:amount 1000.00M :created_at "2019-12-27"}]}}))

Also, while you should most likely use a map, if you insited on using a vector, you can also update it the same way:

(dosync (alter accounts update-in [2 :transactions] conj new-tx))

thanks @U0K064KQV and @U0NCTKEV8 I changed to use maps and now it works perfectly

(into orig-coll (map fn (filter ffn orig-coll)))

I'm assuming you mean you want to keep the values that don't meet the filter criteria

if you specifically want to avoid the intermediate lazy sequences. then transducers can do that. but that's more an optimisation than anything different

I always thought that the map and filter, how it is written in your example is considered two walks

Technically, yes, it will create extra intermediate lazy sequences, but whether that matters in practice is a different question.

it's lazy. so it's sort of two walks. if you want to make it "definitely only a single walk" you can compose transducers like (into [] (comp (filter ffn) (map fn)) orig-coll)

Is your code performance/memory sensitive? i.e., do you already know that map over filter over coll is too slow/uses too much memory?

This part of the code needs to be performant as much as I can get it to be

its not dire

imo I would measure the difference with real data with a real use case. but transducers are in general going to be faster

No, it is not two walks

It gets a bit complicated, but the overhead isn't in having to do more looping, but in having to create intermediate objects.

And that overhead is further reduced by the use of chunking

So in practice, lazy-seqs will often be just as fast

Which is why people say you should measure it, because sometimes the non lazy-seq version is actually slower

Think of it as a pull model

You want the first element that matches the criteria, and you want it transformed

So it will start looping on the collection until it finds the first element that matches the filter predicate. When it finds it, it will stop looping, and return the found element and apply the map function to it. Done

When you then ask for the second element, it will resume looping where it last left off

But to do this "resuming", you need to keep track of additional data, that tracking is the overhead which makes lazy-seq potentially slower

To reduce the amount of tracking required, Clojure pulls in chunks of 32 at a time. So it only needs to track what is left every 32 elements.

That even when you ask for the first element only, it will actually pull in the first 32 elements, thus it will loop over the first 32 elements, and then stop there, and it will remember that it must now loop at element 33 next.

Those first 32 elements will be cached. So if you ask for the second element, it is already available in the cache, an no more looping, filtering or mapping was needed.

Only once you ask for an element greater than 32 will it resume the loop, and filter and map another chunk, etc.

This snippet explains it. This creates an unchunked infinite sequence of 0 to infinity, so 0 -> 1 -> 2 -> 3 -> 4 ... The sequence will print the index it is currently iterating over as f: i Now I take the first, and you see it prints f: 0. If I take the second, it prints f: 2. And when I take the third f: 3, etc. See how it didn't have to loop over 1 and 2 again? It just continued from where we were last. Even though I am doing a filter followed by a map. The filter and the map happen one after the other per element. Each element is only visited once.

Look at this snippet as well, might help you understand. See how when using the eager filterv and mapv it first filters everything, which is one loop over 4 elements, and then it maps everything, which is another loop over the 4 elements returned by filterv. But when using the lazy filter and map, it grabs the first element and then filter and map it, and then move to the next element. Thus it is a single pass. While using the transducer element, it similarly did a single pass, and filters and maps element by element, but it all happened before the call to a because it is eager? The only difference thus with the lazy-seq is that the transducer didn't ever have to remember where we were and didn't have to create an intermediate checkpoint if you want after each iteration, where the lazy-seq did, it had to create a new lazy-seq of the remainder after each iteration.

@U0K064KQV Thank you for this! It actually completely changed my understanding (lack thereof) of lazy-seq's! Just copied and pasted this onto my bear notes 😄

😄, glad I could help

Yes