[cutler]

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]

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]

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]

> 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]

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]

”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.

[Too]

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.

[localhostdotdev]

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