3 ms·
I understand how type annotations are useful for users and also for static analysis tools (called Dialyzer in Elixir/Erlang), which is exactly why I didn't see
by bmitc 5y ago
I understand how type annotations are useful for users and also for static analysis tools (called Dialyzer in Elixir/Erlang), which is exactly why I didn't see why code completion would be one's primary reason for wanting them. However, in Python's case with heavy use of OOP and dot notation, I suppose I could see it being beneficial if the tools pickup up type annotations for code completion (still not the primary reason though) as opposed to something like Elixir. In Elixir, types and modules are tightly coupled, which means user's being implicitly being aware of types and also code completion generally working without type annotations (which can be inferred by Dialyzer anyway).
So your comment actually backs mine up. I don't know why code completion would be the tipping point for type annotations when their usefulness to users and static analysis tools are already enough. Documentation for users is in fact enough to have them.
- rbanffy 5y agoIt could have been that code completion was the feature Guido saw would seal the deal with users. Good code completion is a great tool for exploratory coding. I frequently found about new APIs through the IDE before reading the documentation. This has been extremely valuable since Visual Basic 3, IIRC. I like it - sometimes I want something to really take an integer (or an explosive bolt) and not any number (or a warhead). If I can say that the argument is supposed to be something, then it's harder to the IDE user to misuse it with unpredictable results. Or, if my library or function can do something I never expected it could, I welcome the patch to make it obvious.