Fork me on GitHub
#clojuredesign-podcast
<
2019-10-15
>
jumar03:10:18

I guess that's the usual approach but Chris and Nate have been advocating namespaced maps I believe 🙂

nate03:10:31

nesting maps is definitely a common approach

nate03:10:48

we've found that flattening maps leads to simpler code: fewer calls to get-in to dive into deeply nested data structures

nate03:10:09

of course, nesting is still used for sub-entities

nate03:10:44

for an example of what namespacing can do, look at Stuart Halloway's example here: https://youtu.be/Qx0-pViyIDU?t=1463

nate03:10:20

you could structure that data as nested maps, but using rich keys makes it unnecessary

nate03:10:21

oh, I see what you mean

nate03:10:38

yeah, unmixing data is much easier with nested maps

nate04:10:32

I'll have to try it out.

Stefan05:10:33

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,..

neumann15:10:07

@UGNFXV1FA I think that's great advice! Thanks! I totally relate to wandering off on "expert picks". Make progress first. Optimize later. 🙂

Stefan05:10:21

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 🙂

jumar06:10:17

I think not necessarily right from the start.

Stefan06:10:42

Agreed! But when then? 🙂

jumar06:10:44

Of course is useful to learn the most used functions - for this books like Programming Clojure + exercises like 4clojure might be useful

jumar06:10:33

Probably similar to the "spend at least a year" advice but it really depends

jumar06:10:42

Whenever you find a strong desire to do so 🙂

jumar06:10:00

For that I'd consider https://www.manning.com/books/clojure-the-essential-reference + reading the clojure.core source code

Stefan06:10:03

Yeah I guess that’s as good an answer as can be expected 🙂

Stefan06:10:34

Ah that seems like an interesting book!

lodin12:10:06

@UGNFXV1FA 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.

👍 4
neumann15:10:08

@UGNFXV1FA 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

neumann15:10:58

But yes, more substantive problems like the ones on 4clojure will also introduce you to more uses.

neumann15:10:10

Definitely read other folks answers to Advent of Code!

neumann15:10:38

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

Stefan18:10:23

Yeah I’m looking forward to that, thanks Christoph!

iGEL06:10:01

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?

neumann15:10:42

@U3UDMF5ME 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. 😁

😄 4
neumann15:10:57

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)

neumann15:10:55

And then, of course, the ceremony just multiplies if you want to sort by name and then ID.

neumann15:10:50

(sort-by (juxt #(-> % :player :name) #(-> % :player :id)) players)
vs
(sort-by (juxt :player/name :player/id) players)

neumann15:10:13

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.

neumann15:10:43

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.

neumann15:10:12

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])

neumann15:10:49

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}})

neumann15:10:38

Or maybe

{:team (select-keys (:team player) [:id])
 :player (select-keys (:player player) [:id :name])}

neumann15:10:49

I prefer the rich keys.