It is not at all trivial to see what a function is supposed to do from its type sig. There are an infinite number of valid type safe implementations for:
transform(a: number): number transform(a: number): number function transform(a: number | string): number | "" | false
Static typing doesn't just tell you what's going on, but it also helps you keep your implementation honest with your intent. It's also why it's a good habit to annotate top-level functions instead of relying on their inference.
function transform(a: number): number
function transform(a: string): false
function transform(""): ""
> Once you are able to comfortably read type signatures, it is trivial to see what a function is supposed to do
Typing gives minimal insight into what a function actually "does".
The solution is intention revealing naming, available in all languages.
You see "Put an object with these properties and types in, get an object of this shape back out."
The beauty of types is in this black-box, abstract behavior.
You, as a library author, can define an Interface/Contract for the behavior of something completely abstractly, and other people can all use each other's implementations or contribute original ones because they obey the contract.
Think about an "Abstract class File, which implements open, read, and write."
There are a lot of ways you could write these methods but if your type signatures match the inputs and outputs they're all equally valid with predictable behavior.
Design by contract is a beautiful thing.