3 ms·
> no boolean answer we could give would satisfy the principle of least surprise I think True follows the principle of least surprise. > I don't think there's
by wyager 7y ago
> no boolean answer we could give would satisfy the principle of least surprise
I think True follows the principle of least surprise.
> I don't think there's anything particularly related to 'functional programming' about the arguments used here
It imparts a better understanding of algebraic abstractions, including what it means to recursively reduce a data structure.
I'm not sure how that python code is supposed to be especially simple or elucidating. I think the following Haskell code is reasonably elucidating, since it elides any need to manually define a special case or base case:
all = getAll . foldMap All
Where "All" is the conjunction ("and") monoid, as defined in Data.Monoid.
- eru 7y ago> I think True follows the principle of least surprise. Me too. I was just quoting the best argument (I found so far) for a different position. > I'm not sure how that python code is supposed to be especially simple or elucidating. I think the following Haskell code is reasonably elucidating, since it elides any need to manually define a special case or base case: The Python code wasn't for comparison to any Haskell implementation. If you can read Haskell, you'll likely prefer the Haskell version. But that's not the point. The point is that amongst all imperative attempts, the most straightforward ones also naturally suggest what to do about the empty list. Btw, in Haskell notation most normal people's mental model of how 'all' works is probably closer to: all = foldl1 (&&) Most normal people don't think about neutral elements of operations, and that they suggest a natural answer for folds over empty collections.