> It's true that you use this way of programming so often in functional languages that it earned itself a name, so that it's easier to talk about it. However ca

> It's true that you use this way of programming so often in functional languages that it earned itself a name, so that it's easier to talk about it. However calling it a 'pattern' feels weird (to me), even though it technically is one. > The equivalent of accumulators in imperative languages would be the 'pattern' of having some variables outside of the loop and mutating them from within the loop. Maybe you can appreciate that it feels weird calling this a 'pattern' — and now you can better understand how I feel about accumulators being called a pattern. That's a fair point, actually. I read "patterns" as "design patterns" a la the book of same name, based on the implied^Wlater stated title "accumulator pattern", but I agree it does fit a weaker notion of "pattern" such as "less-than-maximally-entropic (aka compressible in the information-theoretic sense) feature of code".