Names of parameters in get-jovian-moon (sample, chapter 1)

[Paul Brabban]

Hey Zach,

Thanks for writing this book - I was excited to hear you're close to finishing on the podcast I listened to the other day.

I'd like to query one detail in the sample chapter though, if I may (haven't bought it yet but I plan to, so sorry if you've addressed this already in the full copy)

So, we have a function (get-jovian-moon [m k] ... ) and you say that the parameters have reasonable names. You later make the point about choosing narrow names for most code. I'd argue that this first example's parameters could and should be a lot narrower.

'm' and 'k', i.e. 'map' and 'key' are about as high level as it gets, and if we were writing assoc or dissoc it'd make perfect sense to use these names, as assoc and dissoc will really work with any map and key. In this case, the map must follow a certain structure and the key must represent a Jovian moon. An arbitrary map and key will return nil.

I think you covered better names later in the chapter - something like (get-jovian-moon [system->planet->moon moon] ... ), assuming there's no well known name for a map with this structure in the domain.

I'm particularly interested because if a skilled mentee gave me that function definition, I'd make this point and I'd put it in a context of "avoid mixing different levels of abstraction in the same function definition" - in this case, the function does something very narrow, but then the much more abstract 'm' and 'k'. If there's some reasoning I'm not aware of going on here feel free to put me right.

I hope this is a useful question - and that it hasn't already been asked and answered somewhere! Thanks again for all your hard work on this book and your libraries.

Thanks,

Paul

[Zach Tellman]

Hi Paul,

You're completely right, `m` is not an ideal name in the context of the function.  I had meant to elaborate on this in the latest draft (I have received this feedback, but not on this mailing list), but it slipped through the cracks.  I was trying to figure out whether to elaborate on this at the beginning of the chapter, call back to it at the end of the chapter, or both, and I ended up doing none of the above.  

Thanks for reminding me, I'll be sure to improve on this in my next release.

Zach

--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clo...@googlegroups.com.
To post to this group, send email to elements-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elements-of-clojure/843ca8d4-ed6c-4270-a7c9-596283396246%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Brabban]

Hey Zach,

Glad to be of help. Nice to know that you're only human like the rest of us :)

Paul

On Wednesday, 16 May 2018 23:11:40 UTC+1, Zach Tellman wrote:

Hi Paul,

You're completely right, `m` is not an ideal name in the context of the function.  I had meant to elaborate on this in the latest draft (I have received this feedback, but not on this mailing list), but it slipped through the cracks.  I was trying to figure out whether to elaborate on this at the beginning of the chapter, call back to it at the end of the chapter, or both, and I ended up doing none of the above.  

Thanks for reminding me, I'll be sure to improve on this in my next release.

Zach

On Mon, May 14, 2018 at 6:29 AM Paul Brabban <paul.b...@gmail.com> wrote:

Hey Zach,

Thanks for writing this book - I was excited to hear you're close to finishing on the podcast I listened to the other day.

I'd like to query one detail in the sample chapter though, if I may (haven't bought it yet but I plan to, so sorry if you've addressed this already in the full copy)

So, we have a function (get-jovian-moon [m k] ... ) and you say that the parameters have reasonable names. You later make the point about choosing narrow names for most code. I'd argue that this first example's parameters could and should be a lot narrower.

'm' and 'k', i.e. 'map' and 'key' are about as high level as it gets, and if we were writing assoc or dissoc it'd make perfect sense to use these names, as assoc and dissoc will really work with any map and key. In this case, the map must follow a certain structure and the key must represent a Jovian moon. An arbitrary map and key will return nil.

I think you covered better names later in the chapter - something like (get-jovian-moon [system->planet->moon moon] ... ), assuming there's no well known name for a map with this structure in the domain.

I'm particularly interested because if a skilled mentee gave me that function definition, I'd make this point and I'd put it in a context of "avoid mixing different levels of abstraction in the same function definition" - in this case, the function does something very narrow, but then the much more abstract 'm' and 'k'. If there's some reasoning I'm not aware of going on here feel free to put me right.

I hope this is a useful question - and that it hasn't already been asked and answered somewhere! Thanks again for all your hard work on this book and your libraries.

Thanks,

Paul

--
You received this message because you are subscribed to the Google Groups "Elements of Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elements-of-clojure+unsub...@googlegroups.com.