Hacker News new | ask | show | jobs
by adimitrov 2618 days 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.
1 comments
cutler 2618 days 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.

link
Faark 2618 days 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.

link
mcintyre1994 2618 days 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.
link
Someone 2618 days 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.

link