undefined | Better HN

0 pointsblindseer4y ago0 comments

My approach has been by default to never use types in functions, and if I use types, use the most abstract type possible, only in order to trigger dispatch.

1) It is just hard to explain this to people that work under me. 2) types in functions are no longer useful to understand the code or improve readability, since the purpose of types is only for dispatch.

I guess my dream request would be an alternative syntax for typing for concrete and abstract types. Abstract types would be used for dispatch and composibility. Concrete types should be used because the function is being specialized for that concrete type.

There's lots of nuance here though, and I've really struggled to communicate this to colleagues and peers.

0 comments

1 comments · 1 top-level

oivey4y ago

Fair enough. I'm not sure what fueled this idea that marking variables with types will make the code faster. Cython? I think part of the issue, too, is that in Python type annotations are really just fancy comments. If you mark a function as taking ints in Python and stick a double in, at most your editor or mypy will complain. If you do it in Julia, it's a compilation error. Tangent: JET.jl might catch these sorts of issues for you and I think has linter support in VS Code now or imminently.

I'm not sure being able to subtype concrete types will help with the specific issue you're showing here. Really the right thing to do is make the function take Numbers. If you allowed Int to be subtyped, things would still be semantically wrong, and you would have introduced a parallel inheritance tree that will break a lot of the interoperability multiple dispatch enables.

j / k navigate · click thread line to collapse