Good thing the input isn't unknown then.

I'm responding to a comment on the actual answer, so I don't understand how I'm spoiling anything?

It's a function using its single argument to create a new function, only to apply it to that same argument. You could rewrite it using do-notation as such:

fun = do
  x <- head
  \xs -> toUpper x:tail xs -- or `(:) toUpper x . tail`

I guess the tricky part is realizing that head will get applied to the same value that xs represents, similar to how in the IO monad, you always write to the same enivironment you read from, and thanks to monads, this all happens implicitly. I generally think of monads as computations that can be composed/sequenced within a specific environment that they can interface with, without explicit references, a kind of meta-argument given at the start of the computation, in this case just a simple String.

As for the (. tail) . (:) . toUpper part, it might be helpful to think of function composition as any other binary operator. Composition is defined as:

f . g = \x -> f (g x)

So once it has an argument, it'll first get applied to function right of ., and its result gets applied to the function left of it. For simplicity, let's define cons = (:) and rewrite the partially applied (. tail) to (\f -> f . tail), then we can work out the following:

(\f -> f . tail) . cons
 => \k -> (\f -> f . tail) (cons k)
 => \k -> cons k . tail
 => \k -> (\y -> cons k (tail y))
-- let's compose that with `toUpper`
(\k -> (\y -> cons k (tail y))) . toUpper
 => \x -> (\k -> (\y -> cons k (tail y))) (toUpper x)
 => \x -> (\y -> cons (toUpper x) (tail y))
-- and thanks to currying
 => \x y -> cons (toUpper x) (tail y)

So we have a function that capitalizes a Char, and "conses" it to the tail of a String, and because of (head >>=), the Char will materialize from the same String tail will get applied to, giving us an overly complicated yet succint way to capitalize the first letter of a word.

I'm not sure why I actually wrote it like that though, if I were to redo it, I'd use:

(:) <$> toUpper . head <*> tail

Which does the exact same thing, but for different reasons and without monads.

I think you meant to refer to the "pigeonhole principle" instead of the birthday paradox.

A polynomial time solution to a linear time problem should never be considered "Best Practices"

It uses the mathematical understanding of a set, but you can think of it as a hashmap with only keys and no values, so unordered (can't use sort) and no duplicates.

Did you actually look at the code? They didn't use encode.

If I were to make a translation, I would include division by zero in the tests, and make sure it throws an exception, because that's the only acceptable result for it.

Saying it's zero is literally no different than saying 1 equals 2.

What the hell, this is straight up wrong. 1 / 0 should not return 0.

You're not being smart for "handling" division by zero this way, because that would imply mathematicians, calculators, computers are dumb for not allowing it.

If 1 / 0 == 0, then 1 == 0 * 0, which is obviously bullocks. And if 2 / 0 == 0, then 2 == 0 * 0 == 1, who wants to use a calculator that literally thinks 1 == 2?

The distinct & sorted StringOps methods have been deprecated in Scala 2.13, which wouldn't be much of an issue, except that right now this solution prints itself to STDERR when hitting submit, allowing the users to view it before fully solving it themselves.

The Scala solution uses deprecated StringOps methods which get printed to STDERR whenever you hit submit, basically giving itself away to the user.

I had heard that foldr can work with infinite lists, but I think this is the first time I've seen a practical application for that (as in it doesn't have to traverse the entire string to start comparing it to the empty one, like I initially thought).