Hacker News Reader

Comment by matsemann | Hacker News Reader

Type inference locally is great. Doing `val something = MyClass()` or `val something = someFunc()` . No ambiguity, just less typing and clutter. At bounds however (function input/output for instance) I prefer explicit types, less chance for mistakes and the signature acts as documentation to what the function does.

View on HN

> Type inference locally is great. Doing `val something = MyClass()` or `val something = someFunc()` . No ambiguity, just less typing and clutter.

As much as I can get behind val something = new MyClass(), where the type is explicitly mentioned on the line, it's a whole other story for val something = someFunc().

You have no way to know the type of that variable without looking at the function itself which is more work than should be needed.

Your IDE/Editor can show that information to you. Having it forced to be written down there just seems unnecessary to me.

The amount of time I look at code outside of an IDE is by far not zero.

Just checking quickly a repository on GitHub for example.

I agree, GitHub should consider adding this feature.

Static typing removes freedom I am addicted to with duck typing, however, I only ship TDD code which also serve as coding documentation. Both are protective but if you're not writing tests then by all means use static typing.

I'm finding this hard to relate to. Our circumstances and experiences must be pretty different. But I'm afraid to me that sentence reads a bit like "I have a lathe so I don't need a bicycle". You or I might not do bicycle jobs, or lathe jobs, but it's a bit of a stretch to imply one renders the other irrelevant.

I find it interesting that you characterise static typing as about safety. I think it's more about communication. (for me this includes "communication to myself when I wrote this seven years ago and didn't think about it since", which I appreciate may be a bit of an edge case). Tests are also a great medium of communication, but a different one - in which case the metaphor becomes swap a sonnet for a sonata? I'd like both please, but maybe not always at the same time :-D

Neither tests nor types are documentation.

> if you're not writing tests then by all means use static typing

I know you're not saying this, but your wording implies it to a bit... Tests to cover <the things covered by static typing> are only one of the uses for automated testing. There's plenty of places (most of them) where automated testing is just as useful with a statically typed language.

Duck typing (structural typing) is orthogonal to dynamic vs static. Typescript being an example of a statically typed language whose type system is centers on structural typing

Reply on news.ycombinator.com