Because 0 is a valid sum for non empty sets, so it’s nice to be able to differentiate between: the items add up to 0 and: there are no items to sum.

It is useful to have the sum and product of empty lists be 0 and 1, respectively.

This means that sum(A ++ B) = sum(A) + sum(B). (++ is concatenation)

And you can have that by using COALESCE(SUM(A), 0) for example.

But COUNT is just a SUM over ones for every row in the output

By what definition? If anything, sums are defined as cardinalities of sets, rather than defining cardinalities in terms of sums.

Then what is a NULL cardinality?

> Option types are way better and always do what you expect.

No, I can implement the exact same weird functions with option types, with signatures

sum: Array<Int> -> Optional<Int>

count_elements: Array<Int> -> Int

FWIW, I personally prefer both functions to not return Optionals, but the point is that the mere presence of Option types in your type system (and the absence of null pointers) doesn't magically eliminate bad library design

imho, aggregation on []<x> should return option<x> unless aggregation on an empty list is exceptional in which case it may throw

What else would the sum/min/max/avg of an empty list be? What else would the count of an empty list be?

What is the sum of an empty list in Haskell? What is its length?

0 and 0 in Haskell