@U883WCP5Z beat you to it. And he agreed my solution was too boring. 😃

Amazing how much there is to learn from seemingly simple tasks.

Absolutely. Never before did I have a kind of zen feeling when learning a programming language. Haskell felt like a complete nightmare compared to this. I've nothing against it. It's just that I try to learn every year, but it never quite clicks 😅

I experienced something like it when I coded in PostScript, but back then there was no www, only me and the books I found. This mentoring layer atop is something else.

In the `iterate`ing fn, the `even?` ensures that `/` returns an int, but if I don't see the `even?` on a first glance, ratios will be in the back of my mind. `quot` wouldn't depend on that context. Not quite following here...

OK. I sort of understand it a bit now. But what is the problem with ratios there?

No problem with ratios. The fact that we're dealing all in integers is made clearer by quot than /. The combination of even? and / makes it equally clear but when I can achieve the same constraints more locally, I prefer that. This piece of code is too trivial for this effect to be prominent. But in larger pieces of code, I sometimes found that when I pulled out a piece of code that relied on constraints maintained by it's context, and tried to re-use it somewhere else, I realise that context, almost always as a bug I'd have to fix later. I'm failing to articulate this clearly too. I've noted this down, and if-n-when I find a precise way to say this, I'll ping you 😄

So, it is that there will never be a ratio produced that you think is made clearer by quot than by /?

quot means you are willing to sacrifice the remainder part. It is indeed clearer when you want to guarantee the result is an integer.

It states your intent clearly.

Exactly what hindol said. Edit: In other words, quot is exactly what you want, and / happens to behave the same way in the context you're in, and also has the additional benefit of slightly better performance. (Take the last part with a spoon of salt. Haven't benched 'em)

I'm not sure I agree. I am not willing to sacrifice any remainder part. I am sure there won't be any remainder part, which is something different, for me.

I mean, quot states your confidence that there won't be any remainder in that case.

But not sure the whole community agrees or not.

Or quot makes sure there is no remainder, while / states my confidence that there won't be any. 😃

/ is probably doing more work than necessary. But unless you're doing performance critical stuff, don't see a problem with either.

I agree with / stating the confidence that there won't be any ratios there, but in the eyes of a reader unfamiliar with the code, they're building up their mental model and constraints on values based on the fns they're seeing. And quot allows them to know that the output will be an int faster than / here because they'd also have to read the even? to understand that. That's what I meant by locality of reasoning. And because it's so minor, and the context is right beside the /, I said it's my pet-peeve and not even a nitpick. We're deep in personal preference land TBH. Edit: I do appreciate well considered discussion on things that seem like trivialities. I for one definitely becomes a better programmer through these things. Thanks for that.

I just told you in a comment, but I'll say it here as well. Please keep up the pedantic level. I want to know about those pet peeves, and get aware of those details. If it was some regular code review situation, maybe I would be more pragmatic about things, but the whole point with a mentored approach is, for me, to learn about all the things.

Now I am curious what other discussions happened. Can you maybe link to the mentored solution (not the published solution)?

You'd have to find all solutions @U883WCP5Z has given me feedback on. 😃 But here is the link to this latest one, anyway: https://exercism.io/my/solutions/9174d6f84ea24b668c2cf0a9b5ef1715

And this one: https://exercism.io/my/solutions/17888633049d4dbe96dc0b9c690ec73c

Unfortunately, I don't think the mentor-mentee interaction can conveniently be made public through Exercism itself.

That would be awesome!

Yeah, cannot see the conversation actually. Capturing the URL before publishing the solution might have worked.

So, can you see the convo here? https://exercism.io/my/solutions/15047d947e1e4b92aa07d34fe3a083bd

I'll wait with publishing until you've checked.

Na, still can't see. What I remember is I opened a solution that I wanted to mentor, left it as it is, and some other mentor commented. I was able to see those comments but not the name of the mentor. May just be a glitch in the system.

Maybe @U883WCP5Z has some link that works?

Nope. Sorry.

There are some traces on the web for something like this having existed: https://twitter.com/exercism_io/status/693466068195495936

Submitted Hamming, FYI. 😃

So, although someone else mentored, I can see the comments by going to this link: https://exercism.io/mentor/solutions/15f6c72d1d824b23b348111b0ae7971a

I want to call out this difference a little,

(map = coll1 coll2)

(map = [[a b] [c d]]) ;; => Arity exception

Also, it might be fun to re-write the above exercise using some-> or some->>.

Regarding inline tests, it seems to be controversial: https://clojureverse.org/t/inline-tests-do-you-do-it/4083 😃