clojuredesign-podcast 2019-09-02

lodin20:09:56

@neumann I have a question regarding your triangle example from episode 42, because I feel like I am missing something. Adding fields with derived data is something I've heard other people talk about as well. What is the benefit of enriching the map with fields and then extract that value (e.g. perimeter or area), over just having a function that computes and returns the value? So (perimeter triangle) or (perimeter (points triangle)) instead of (with-perimeter triangle) and then (:perimeter triangle).

neumann15:09:51

@U8J6W2SC8 Sorry for the slow reply. I just want to let you know that we picked up this question for our episode that comes out later today. There are a couple of different reasons, but one of the main reasons is performance. If you just need the area here and there, you can compute it on the fly with a function. If you want to reference the area over and over (especially in some sort of map/`filter`/`reduce` statement), it's better to have a proper derived field for it.

lodin17:09:30

#Also sent to the channel

@neumann I see. I usually use a Schwartzian transform instead, i.e. construct a new map with the derived keys plus the source data. That works for all data structures, and I can drop the derived values afterwards, or keep them but the structure will make it clear what is derived and what is source data. My general issue with associng derived values onto maps is that if a source key changes then the derived value should (potentially) be recomputed. For instance, if precomputing :area and :perimeter of a triangle, and you make it slanted (moving one point parallel to the line connecting the other two points), then the area stays the same but the perimeter changes. You need to know the intricacies of how the fields relate to each other if you want to update the value, so I play it safe and throw away any derived values, or keep the structure that shows that they are derived.

lodin17:09:30

replied to a thread:@neumann I have a question regarding your triangle example from episode 42, because I feel like I am missing something. Adding fields with derived data is something I've heard other people talk about as well. What is the benefit of enriching the map with fields and then extract that value (e.g. perimeter or area), over just having a function that computes and returns the value? So `(perimeter triangle)` or `(perimeter (points triangle))` instead of `(with-perimeter triangle)` and then `(:perimeter triangle)`.

@neumann I see. I usually use a Schwartzian transform instead, i.e. construct a new map with the derived keys plus the source data. That works for all data structures, and I can drop the derived values afterwards, or keep them but the structure will make it clear what is derived and what is source data. My general issue with associng derived values onto maps is that if a source key changes then the derived value should (potentially) be recomputed. For instance, if precomputing :area and :perimeter of a triangle, and you make it slanted (moving one point parallel to the line connecting the other two points), then the area stays the same but the perimeter changes. You need to know the intricacies of how the fields relate to each other if you want to update the value, so I play it safe and throw away any derived values, or keep the structure that shows that they are derived.

2019-09-02

Channels