nth doesn't hold the head

I think the answer is something to do with handling lazy sequences. The function call will happen n times and if it produces a lazy sequence then the nth function will only cause the iteration to happen n times. If the iterate function does not create a lazy sequence then you will see more than n calls to the function. Although Clojure is calling the function the normal view is to look at the data rather than the function call. So hence my suggestion about lazy sequences.

• I've lost count how many times I've faced this dilemma and after a lot of consideration mostly ended up with plain functions. It works for the most part but needs more discipline to keep code organized neatly and I feel I'm missing out on something, like I'm underutilizing Clojure. • I like multimethods and I've used them a bunch because they promote a more data-oriented approach to solving problems than records/protocols but on the other hand you have to rely on namespaces and your eye to group operations together. That's not necessarily a bad thing but it's menial work that you don't have to think about if you use protocols. • Namespace (re)loading also gets weirder the more you use any of these (you have to make sure you've loaded all namespaces that contain the multimethods, even though they don't seem to be used, which can also throw linters off), so it's probably an additional thing to consider if your workflow depends on that?

I'm aware of the performance aspects of each (i.e. protocols are faster than multimethods) but I suppose what I'm trying to understand here is, performance and other technical considerations aside, which approach leads to simpler code that is easier to develop/refactor/accrete over time?

I have an alternative perspective for you. Protocols and multimethods just define a named switch statement that is extensible after it's defined. Performance aside, the least complex thing is to not use these extensible systems and just use if/`cond`/etc. Multimethods allow you to define the function to switch on, and protocols only allow you to use java's type dispatch mechanism. There are reasons extensibility is useful, for example code ownership (if the switch statement is in a library, not part of the application, then being open to extension can be useful) or code co-locality (a bunch of different things seem to naturally fit together so you want to write their implementations next to each other) but I think it's always more straight forward to start with normal functions and only add the more complex structures when you really need them. Don't worry that you're missing out 😉

Good point about code ownership! > code co-locality (a bunch of different things seem to naturally fit together so you want to write their implementations next to each other) Yes, that's it, I suppose I'm trying to find a way to marry convenience to simplicity in this scenario. As in, if you use conditionals, you have to describe the dispatch logic as you're writing the code. But with multimethods/protocols you design it once and then it's easier to use because it's abstracted away from the user (it's more convenient but complex). > I think it's always more straight forward to start with normal functions and only add the more complex structures when you really need them That's what I've been doing for the most part but I'm not sure I'll ever "really need" any of these. Anything that you do with multimethods/protocols you can do with conditionals, so how do you tell when to switch?

Doesn’t it boil down to open vs closed? You’ll need to know all options in your conditional, whereas other options are more dynamic and extensible, even outside of your own code. Then protocols dispatch on type, so you might prefer multimethods when dispatch is more complex, perhaps dispatching on a value or some other logic?

Then protocols dispatch on type, so you might prefer multimethods when dispatch is more complex, perhaps dispatching on a value or some other logic?Good point... Assume that both are applicable in this case (let's say S3Storage/LocalStorage/DBStorage are custom types, so you can use those to dispatch with protocols)

The nice thing is that I don’t it’s that difficult to change your approach later. Unlike when I used to code in more static languages, when it feels as if perhaps you’re more locked in to the pattern, it’s not difficult to switch and clients don’t necessarily need to change much, if at all. So get something working and then make more complex if you really need it.

Sounds to me like a protocol is your best bet.

You’re likely to then have some configuration options so you’ll have a factory of the type of thing and then all other code just calls your protocol(s) with the opaque thing. If you changed stuff in the future, most of the polymorphism is kind of opaque to callers anyway… they just work to whatever abstraction you’ve designed.

So get something working and then make more complex if you really need it.That's good advice... > You’ll need to know all options in your conditional, whereas other options are more dynamic and extensible, even outside of your own code. Not an issue, it's an internal thing, so only people with access to the existing code will try to extend it. > Sounds to me like a protocol is your best bet. Even over plain conditionals? This is a fresh perspective 🙂 Would you prefer conditionals if neither extensibility nor complex dispatching is a goal or do you find merit in protocols/multimethods besides those two?

:man-shrugging: … no “right” answer but I can only keep so much in my head at the same time, so what you’ve described to me sounds as if it’s an important boundary. When I’m wearing a “client hat” I don’t want to know the impl details, and when I’m wearing the “impl” hat, it feels to me as if you have types that are little machine type things and you already have multiple impls so keeping things open and extensible resonates… but I think this is more art than science? Sometimes you only grok the proper boundaries later, and after a few implementations so you end up with a coding iteration that is quite different in Clojure compared to say, Java, when you’re natural tendency is to think you know everything upfront and start writing interfaces with only one implementation. That’s why I’ve so enjoyed Clojure because that iteration aspect is so easy and probably gives better results?

Is that an example of deferring decisions until as late as possible… probably.

I like plain functions unless there's a specific reason they aren't up to the job.

<https://www.youtube.com/watch?v=t6ktSfInNhU> is a talk from way back where chouser talks about the expression problem (which is sort of a special case within the concept of polymorphism). The coverage of mutlimethods and protocols starts at about 14:00, and talks about the pre-reqs and trade-offs of each