3 ms·

Annotated return types are one of the single most prominent readability benefits of typed syntax. Knowing with certainty what type will be returned in a single

Annotated return types are one of the single most prominent readability benefits of typed syntax. Knowing with certainty what type will be returned in a single brief glance, without the cognitive overhead of parsing function body and checking various return statements (at best: returning a variable obtained from an external source may obscure type further). For me this also greatly improves my ability to refactor quickly and confidently (not needing to check additional places/files during refactor for edge cases in expected type). Yes any type-related refactor mistakes should in theory be picked up at compile time, or by smart IDEs but having the context in front of you still greatly improves speed when writing. It's also great for code reviews where grokking context is trickier and IDE goodies are typically not as rich.

breck 6y ago
> in a single brief glance this is something VSCode/editors could always show if desired via secondary notation, without requiring annotations.
- lucideer 6y ago
  IDEs are great and all, but their features should be an augmentation of the usefulness of the language, not a requirement. I've already mentioned code reviews as a good example of contexts where we need to read code outside of an IDE regularly, but even beyond that, a language's readability shouldn't be dependent on using some specific environment to read it.
  - breck 6y ago
    The LSP pattern allows for bringing anything you’d find in an ide to other targets (like code review tools, as used by GitHub). I used to be a language purist, but nowadays the costs of not using an ide or lsp supported tools is just too high. I’d prefer minimal tokens and abundant secondary notations provided by parsers than having to add clunky syntax myself.
    - lucideer 6y ago
      > language purist Maybe I'm in a minority but calling anyone using type annotation "language purists" seems a bit of an extreme classification.
      - breck 6y ago
        I meant I used to believe that a language should be designed to be used notepad first. Now I believe it should always be usable in notepad as a fallback, but the design of the language should be heavily influenced by what capabilities IDEs/LSPs can bring. So IDEs first but never violate the rule that it's easy to fix something in vim or notepad in a pinch.
  - ragnese 6y ago
    I have mixed feelings on this. On the one hand, I'm like you. I don't want to be forced to use a specific tool to work with a programming language. But I can't quite put my finger on why. Like, what if we just say "language Foo includes a compiler and the working environment is this IDE"? Is that wrong? It kinda feels wrong. But that's what Smalltalk does, right? Maybe the tight integration would actually be better.

breck 6y ago

> in a single brief glance this is something VSCode/editors could always show if desired via secondary notation, without requiring annotations.

lucideer 6y ago
IDEs are great and all, but their features should be an augmentation of the usefulness of the language, not a requirement. I've already mentioned code reviews as a good example of contexts where we need to read code outside of an IDE regularly, but even beyond that, a language's readability shouldn't be dependent on using some specific environment to read it.
- breck 6y ago
  The LSP pattern allows for bringing anything you’d find in an ide to other targets (like code review tools, as used by GitHub). I used to be a language purist, but nowadays the costs of not using an ide or lsp supported tools is just too high. I’d prefer minimal tokens and abundant secondary notations provided by parsers than having to add clunky syntax myself.
  - lucideer 6y ago
    > language purist Maybe I'm in a minority but calling anyone using type annotation "language purists" seems a bit of an extreme classification.
    - breck 6y ago
      I meant I used to believe that a language should be designed to be used notepad first. Now I believe it should always be usable in notepad as a fallback, but the design of the language should be heavily influenced by what capabilities IDEs/LSPs can bring. So IDEs first but never violate the rule that it's easy to fix something in vim or notepad in a pinch.
- ragnese 6y ago
  I have mixed feelings on this. On the one hand, I'm like you. I don't want to be forced to use a specific tool to work with a programming language. But I can't quite put my finger on why. Like, what if we just say "language Foo includes a compiler and the working environment is this IDE"? Is that wrong? It kinda feels wrong. But that's what Smalltalk does, right? Maybe the tight integration would actually be better.