Hacker News

> reduce is less elegant in languages I use, like JavaScript, Python, and Swift. In my blissful stint as a Clojure developer, I did not get this feedback.

Two notes:

1. reduce if a part of functional programming vocab, so, obviously, a Clojure dev has to internalize it to be able to use the language properly. For other mentioned languages it is not that necessary.

2. As a (mostly) Python dev, I think that list comprehensions and generator expressions are much easier to read and understand than map and filter. Although, people coming from other languages and having limited experience with Python specifically might disagree with me. Perhaps, we should think about inventing some nice syntax sugar that around the concept of `reduce`ing and `fold`ing, similar to what list comp/gen expr in Python did to concepts of `map`ing and `filter`ing.

vova_hn2 6 hours ago [ - ]

Actually, now that I think about it, with this new(-ish) (in)famous walrus operator and itertools recipes, I could sort of emulate reduce using gen expr

First, I will need to steal a "consume" function from Itertools Recipes [0]:

    from collections import deque
    from itertools import islice
    
    
    def consume(iterator, n=None):
        "Advance the iterator n-steps ahead. If n is None, consume entirely."
        # Use functions that consume iterators at C speed.
        if n is None:
            deque(iterator, maxlen=0)
        else:
            next(islice(iterator, n, n), None)

Isn't it a bit weird, that the fastest and easiest way to consume an iterator entirely is to feed it to a zero length deque? It is weird, but it was just an apéritif, lets move to the main course:

    lst = [1, 2, 3]
    acc = 0
    consume((acc := acc + item for item in lst))  # this is the actual reduce
    print(acc)

This is the line where the actual `reduce`ing happens:

    consume((acc := acc + item for item in lst))

Basically, we use the fact that a "walrus" expression has a side effect and we just throw away the actual results of the iterator, because we don't need them.

Is it more readable then normal reduce? I'm not sure. If I seen it in the actual production code, it would certainly raised my eyebrows. It is not a part of the normal Python "vocab" - a set of idioms that are considered "pythonic" and that you expect every Python dev to intuitively understand, so I would be very cautious in using it in the code that is intended to be read by other people.

Why did I do it? I don't know, just a fun "what if?" thought experiment.

[0] https://docs.python.org/3/library/itertools.html#itertools-r...

vova_hn2 6 hours ago [ - ]

Of course it is also possible to just create a temporary list and throw it away immediately:

    lst = [1, 2, 3]
    acc = 0
    [acc := acc + item for item in lst]  # this is the actual reduce
    print(acc)

This way you wouldn't need to take that weird function from Itertools Recipes.

It should be possible to optimize away the creation of the temporary list and avoid wasting CPU and memory on it. But I don't know if CPython actually has this optimization, that's why I didn't mention it initially. I would love someone more knowledgeable in CPython internals to tell me how this would work.