why not just use nested maps if that's how the data needs to be accessed?
also I wonder if meander would be good for this use case
I guess that's the usual approach but Chris and Nate have been advocating namespaced maps I believe π
nesting maps is definitely a common approach
we've found that flattening maps leads to simpler code: fewer calls to get-in to dive into deeply nested data structures
of course, nesting is still used for sub-entities
for an example of what namespacing can do, look at Stuart Halloway's example here: https://youtu.be/Qx0-pViyIDU?t=1463
you could structure that data as nested maps, but using rich keys makes it unnecessary
I just mean that if you need to access all the keys with a given prefix then that probably means you're better off nesting maps
barring other constraints
oh, I see what you mean
yeah, unmixing data is much easier with nested maps
but yeah, medley has a filter-kv that might do the trick for filtering on the key namespace. unfortunately that also means iterating over the entire map, though :(
oh, it has filter-keys too
I'll have to try it out.
Hi guys, I just listened to your episode #37 about, well, me basically π One piece of advice I would give other beginners is to choose an IDE and stick with it for a while. Like, minimum a year or so. In this stage of your learning it really doesnβt matter which one, all of them are good enough. Just use what youβre familiar with. I find Iβm constantly tempted to try other thing because of stuff I hear experts say, and before you know it your learning editors and plugins instead of Clojure,..
@stefan.van.den.oord I think that's great advice! Thanks! I totally relate to wandering off on "expert picks". Make progress first. Optimize later. π
Liked the episode by the way. I also found out about Clojure Koans early on, which I liked, and this year I plan to do Advent of Code in Clojure. Regarding all the goodness in clojure.core
, Iβve been wondering whether I should spend time to sit down and go through the whole thing, function by function, on clojuredocs for example. On the one hand Iβm sure I would learn lots of valuable things, on the other hand Iβm a bit wary of the amount of time and effort it would require π
@stefan.van.den.oord A great way is to check the cheat sheet. If you need to do eg a sequence transformation, check all the seq functions before writing it. I usually use the cheat sheet as an index anyway.
@stefan.van.den.oord I've found it useful to open the Clojure Cheat Sheet, skim through it, look for a function I haven't seen before or I don't know very well, and then read about it. Then put it down, and do that again tomorrow. Combine with a morning coffee to great effect! https://clojure.org/api/cheatsheet
But yes, more substantive problems like the ones on 4clojure will also introduce you to more uses.
Definitely read other folks answers to Advent of Code!
One year I read all of Mike Fikes's and Bruce Hauman's answers. I learned so much! https://github.com/mfikes/advent-of-code https://github.com/bhauman/advent-of-clojure
Yeah Iβm looking forward to that, thanks Christoph!
I think not necessarily right from the start.
Agreed! But when then? π
Of course is useful to learn the most used functions - for this books like Programming Clojure + exercises like 4clojure might be useful
Probably similar to the "spend at least a year" advice but it really depends
Whenever you find a strong desire to do so π
For that I'd consider https://www.manning.com/books/clojure-the-essential-reference + reading the clojure.core source code
Yeah I guess thatβs as good an answer as can be expected π
Ah that seems like an interesting book!
Hi. Just a small correction to the nil punning episode (sorry if mentioned before): Ruby just like Clojure only evaluates nil
and false
to false
, everything else is truthy. Maybe you meant to say PHP at 14:00?
@igel Did we say that about Ruby? Good catch. We've both worked with Perl the most, and I think we might assign some of Perl's attributes to Ruby sometimes. π
I missed all the fun discussion about rich keys. We'll have to talk about that on the podcast. My short opinion is that they involve a lot less ceremony than nested maps, so your code gets simpler. For example, suppose you want to sort by player/name
. That's:
(sort-by :player/name players)
instead of
(sort-by #(get-in % [:player :name]) players)
or even
(sort-by #(-> % :player :name) players)
And then, of course, the ceremony just multiplies if you want to sort by name and then ID.
(sort-by (juxt #(-> % :player :name) #(-> % :player :id)) players)
vs
(sort-by (juxt :player/name :player/id) players)
At least for what Nate and I work on, it's useful to think of a map as a bag of dimensions that can grow or shrink. We have data pipelines, so we may start with a map that just has IDs in it, but then we enrich it with other data.
Likewise, we may have a map with lots of rich information in it (because it's not normalized), and we'll want to pick out all the ID parts for persistence and not save the rich information that got woven in from somewhere else.
Suppose I want to cut down the map to just :player/name
, :player/id
, and :team/name
. So easy with rich keys:
(select-keys player [:player/name :player/id :team/id])
But with nested maps. If want to preserve the same structure. Once again, more ceremony.
(let [{{team-id :id} :team
{player-id :id, player-name :name} :player} player]
{:team {:id team-id}
:player {:id player-id
:name player-name}})
Or maybe
{:team (select-keys (:team player) [:id])
:player (select-keys (:player player) [:id :name])}
I prefer the rich keys.