3 ms·

The biggest problem for me with gradual typing is code clutter. My favourite languages are Clojure and Ruby precisely because they reduce code clutter. What I w

by cutler 8y ago

The biggest problem for me with gradual typing is code clutter. My favourite languages are Clojure and Ruby precisely because they reduce code clutter. What I would prefer, if we are to have types, is for the signatures to go in a companion file. I've never understood why types have to be inlined. A good IDE can easily provide the signature in a mouseover or something similar.

adimitrov 8y ago
The way to reduce clutter in strongly, statically typed languages is to use strong, robust type inference. For example, Java is pretty terrible at type inference (still) and you have to annotate types almost everywhere (Java 8 had a very tepid improvement on that front.) But languages like Haskell and Rust are very good at type inference, and you almost never actually need to specify the types. It's still good Haskell style to always annotate the type sigs of top-level functions. Why? Because they serve as more than just hints to the compiler: they are part (and a very important part!) of the documentation. That is why they're in-line. Because A function like zipWith:: [a] -> [b] -> (a -> b -> c) -> [c] tells you what it does in its type signature.
- cutler 8y ago
  There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup. Java 10 and 11 introduced real type inference, at least for local variables and function parameters.
  - Faark 8y ago
    > There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup. I don't want to go back to having to keep C header file in sync. Your IDE can hide that information from your as well, if you don't want to see it all the time.
    - mcintyre1994 8y ago
      It's been a while since I wrote Ocaml, but IIRC the compiler yells at you if your mli files are out-of-date, for whatever that's worth. So keeping them synced isn't really an issue.
  - Someone 8y ago
    ”There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup” It requires every (1) editor and IDE on the planet to add code for doing that, which means every (1) programming language on the planet needs a library for parsing such companion files, for the benefit of ?????? Except for historical corner cases such as original java with its repeated type annotations that make code with types tedious to read, I wouldn’t know what that benefit would be. (1) that ‘every’ is a bit of hyperbole, but essentially true.
localhostdotdev 8y ago
what's cool is that you can write your types in another directory / another repo, e.g. https://github.com/sorbet/sorbet-typed https://github.com/sorbet/sorbet-typed
Too 8y ago
Types in a companion file?! Every written C/C++ with "companion" header-files? That is clutter my friend. Half of the documentation will be in the header file and the other half in the implementation file and you will have to edit two files for every tiny change you make. No thanks. Types are part of the code and should be as close to the code as possible to reduce any possible source of friction while editing.

by cutler 8y ago

adimitrov 8y ago

The way to reduce clutter in strongly, statically typed languages is to use strong, robust type inference. For example, Java is pretty terrible at type inference (still) and you have to annotate types almost everywhere (Java 8 had a very tepid improvement on that front.) But languages like Haskell and Rust are very good at type inference, and you almost never actually need to specify the types. It's still good Haskell style to always annotate the type sigs of top-level functions. Why? Because they serve as more than just hints to the compiler: they are part (and a very important part!) of the documentation. That is why they're in-line. Because A function like zipWith:: [a] -> [b] -> (a -> b -> c) -> [c] tells you what it does in its type signature.

cutler 8y ago
There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup. Java 10 and 11 introduced real type inference, at least for local variables and function parameters.
- Faark 8y ago
  > There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup. I don't want to go back to having to keep C header file in sync. Your IDE can hide that information from your as well, if you don't want to see it all the time.
  - mcintyre1994 8y ago
    It's been a while since I wrote Ocaml, but IIRC the compiler yells at you if your mli files are out-of-date, for whatever that's worth. So keeping them synced isn't really an issue.
- Someone 8y ago
  ”There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup” It requires every (1) editor and IDE on the planet to add code for doing that, which means every (1) programming language on the planet needs a library for parsing such companion files, for the benefit of ?????? Except for historical corner cases such as original java with its repeated type annotations that make code with types tedious to read, I wouldn’t know what that benefit would be. (1) that ‘every’ is a bit of hyperbole, but essentially true.

localhostdotdev 8y ago

what's cool is that you can write your types in another directory / another repo, e.g. https://github.com/sorbet/sorbet-typed https://github.com/sorbet/sorbet-typed

Too 8y ago

Types in a companion file?! Every written C/C++ with "companion" header-files? That is clutter my friend. Half of the documentation will be in the header file and the other half in the implementation file and you will have to edit two files for every tiny change you make. No thanks. Types are part of the code and should be as close to the code as possible to reduce any possible source of friction while editing.