I wouldn't claim conclusively that the second version is better, but I see Gabriel's point. Yes, the first version is elegant, and it is easier to spot the pred

I wouldn't claim conclusively that the second version is better, but I see Gabriel's point. Yes, the first version is elegant, and it is easier to spot the predicate—but I also can't tell you exactly how the predicate is used, because I don't know the definition of MISMATCH. For example, should a positive result from BAZ mean that the items are the same? There's no way to tell. You could argue that this is because of poor keyword argument naming, but that's part of the point: in the second version, there's no need for such considerations, because the use is explicit. (Consider yourself lucky that the function uses keyword arguments to begin with!) Nor do I agree that the first example is obviously bug-free. How would I know? The definition of the actual logic is in some other file. Yes, that's true for the library functions used in the second example, but those are standardized. Other examples of ambiguities: Are START1 etc counted from the end of the list or from the beginning? What happens if there are several mismatches? What's the time complexity? Etc. Of course these would be part of the documentation, in an ideal world. I should point out that Gabriel isn't arguing that patterns should not be abstracted (or "compressed"), only that there are tradeoffs.