4 ms·

> the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages w

> the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all I recall Guido van Rossum stating once, that he got convinced of the necessity for type annotations by JetBrains explaining to him how hard it was to provide good code completion. Not sure its the full answer, but back then I found it interesting as an example how lobbying can work. (I feel rather indifferent on the type annotations for Python actually, I can see their usefulness, but also the shortcomings of retroactively introducing such a system into a dynamically typed language).

cout 5y ago
Typically in Ruby (which is heavily Smalltalk-influenced) we do ad-hoc type annotations anyway and call it documentation. So you've got the camp that favors type annotations for various reasons and the camp that is opposed. There is also a third camp: the DBC (design by contract) camp. Their argument is that type annotations don't go far enough and that's what you really need is to enforce preconditions and postconditions. While I see their point, I think DBC lacks a "killer app" -- which as you pointed out, for type annotations, is static analysis (which leads to tools like code completion, refactoring browsers, performance improvements, and more).
- dgb23 5y ago
  One „killer app“ for these is interactive programming with instrumentation and generative tests: https://clojure.org/guides/spec https://clojure.org/guides/spec
- rbanffy 5y ago
  > I think DBC lacks a "killer app" If Ariane 5 carried astronauts, it'd certainly be a killer app: https://ieeexplore.ieee.org/document/562936 https://ieeexplore.ieee.org/document/562936
bmitc 5y ago
> I recall Guido van Rossum stating once, that he got convinced of the necessity for type annotations by JetBrains explaining to him how hard it was to provide good code completion. What a weird reason to decide type annotations are useful, but I suppose I am not surprised. And is that really even true? Code completion works fine with Elixir and ElixirLS in VS Code and is seemingly independent of whether typespecs are present or not.
- rbanffy 5y ago
  Type annotations are there to help the user in figuring out what the parameters have to behave like, and, perhaps more importantly, for linters to help finding issues caused by mismatching the types. Invoking the .detonate() method on a pyrotechnic bolt is, usually, far more benign than invoking it on an instance of Warhead. You really want to make sure you don't pass a Warhead to the function you wanted to get only bolts. A linter will warn you about such possible mishaps.
  - 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 ago
      It 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.
blunte 5y ago
> I recall Guido van Rossum stating once There are so many ... interesting ... Python design choices that I'm not sure whether "Guido said" helps an argument or hurts it.
- pjmlp 5y ago
  One line lambdas comes to mind.

cout 5y ago

Typically in Ruby (which is heavily Smalltalk-influenced) we do ad-hoc type annotations anyway and call it documentation. So you've got the camp that favors type annotations for various reasons and the camp that is opposed. There is also a third camp: the DBC (design by contract) camp. Their argument is that type annotations don't go far enough and that's what you really need is to enforce preconditions and postconditions. While I see their point, I think DBC lacks a "killer app" -- which as you pointed out, for type annotations, is static analysis (which leads to tools like code completion, refactoring browsers, performance improvements, and more).

dgb23 5y ago
One „killer app“ for these is interactive programming with instrumentation and generative tests: https://clojure.org/guides/spec https://clojure.org/guides/spec
rbanffy 5y ago
> I think DBC lacks a "killer app" If Ariane 5 carried astronauts, it'd certainly be a killer app: https://ieeexplore.ieee.org/document/562936 https://ieeexplore.ieee.org/document/562936

bmitc 5y ago

> I recall Guido van Rossum stating once, that he got convinced of the necessity for type annotations by JetBrains explaining to him how hard it was to provide good code completion. What a weird reason to decide type annotations are useful, but I suppose I am not surprised. And is that really even true? Code completion works fine with Elixir and ElixirLS in VS Code and is seemingly independent of whether typespecs are present or not.

rbanffy 5y ago
Type annotations are there to help the user in figuring out what the parameters have to behave like, and, perhaps more importantly, for linters to help finding issues caused by mismatching the types. Invoking the .detonate() method on a pyrotechnic bolt is, usually, far more benign than invoking it on an instance of Warhead. You really want to make sure you don't pass a Warhead to the function you wanted to get only bolts. A linter will warn you about such possible mishaps.
- 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 ago
    It 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.

blunte 5y ago

> I recall Guido van Rossum stating once There are so many ... interesting ... Python design choices that I'm not sure whether "Guido said" helps an argument or hurts it.

pjmlp 5y ago
One line lambdas comes to mind.