"Function x will return a list of a"
"Function y will return an instance of b or null"
"Function z will return an instance of c or throw an error"
How much time am I losing by putting that information in the function declaration? I doubt it's more than the time I lose when a function returns or throws something it wasn't supposed to.
Thinking so strictly about what types a function will receive rules out making use of things like decorators in python that operate on function arguments regardless of type.
Or generic validation utils that take many types and return the passed in type after performing internal validation logic relevant to the type.
Those generic use cases are good examples of flexible types, but I have a hard time seeing how
* "I don't know whether the `getMyReplies()` function returns a list of items, an iterator, a non-rewindable generator whose results I need to cache, or a closure with/without memoization" and
* "I don't know whether the singular Reply entity has a field called pid, parent_id, parentId, ParentID, ParentGUID, or parent_message_identifier"
are advantageous to rendering a list of replies.
Languages like C and C++ made it readable with debug symbols.
The web stack does the same with source maps. The TypeScript compiler also offers to emit .d.ts files with type information for reuse in other projects.
Treating the code as statically typed makes the code predictable, less prone to bugs, and easier to maintain. If a function's return type is determined by dynamic factors at run-time, it becomes a maintenance and debugging nightmare; the effect is compounded as more and more unpredictable dynamic functions are chained together.
> operate on function arguments regardless of type
parameterized types and other techniques allow you to describe this type of behavior in a type safe way.
> Or generic validation utils that take many types and return the passed in type after performing internal validation logic relevant to the type.
All these things are possible in typed languages.
Both the things you mention can be done in statically typed languages. The only difference is in dynamic languages you don't have to declare interfaces, subclasses, etc. I just wonder whether that really is as much of an advantage as people think.
I've spend years using both types of languages and I think I think the safety of statically typed languages is usually worth the slight amount of friction it adds.
One example: a function which, when given a single element, returns a single transform of that element. When passed a list of elements, returns a map of that transform over the list. You can argue as to whether that's a good idea or not, but I've seen JS functions that make sense in context which do that.
This might just be my lack of type system expressivity knowledge, but how would one annotate the type of that function? I get that you could use a union type on the param and the return value, but not how you link the two.
Some languages support function overloads like Swift and Kotlin.
fn foo(input: A, xform: A -> B) -> B
fn foo(input: [A], xform: A -> B) -> [B]
https://www.typescriptlang.org/docs/handbook/functions.html#...
This is a limited approach, because the overloads aren't a part of a function type - i.e. you can't have an anonymous function value that is overload-typed, it must be a named function. In principle, a similar mechanism could be used for types as well, it just doesn't usually come up in that context (e.g. callbacks typically don't return different things), which is probably why they didn't do it.
"What about their input and output is" => "what type their input/output is"
The next question is what does the type of the input/output actually tell you about the input/output? In the most popular languages (using interfaces), it basically tells you that the input/output might have a, b and c set (or they might be null), and it could also have anything else set.
So the actual information you have is that you might or might not have (a,b,c) and also might or might not have (anything). Not as foolproof as you think. The natural objection is that aha! I defined this class to require (a,b,c) in the constructor and do a nullity check, so I know much more than this! But this is back to having "types in your head", that constructor signature and nullity check isn't compiler enforced (as in if you change it, nothing will fail in the typesystem at the point of the function that we're checking, as long as those fields remain on the class). So the useful part of the static typing is actually living in your head either way.