11 ms·
Is the problem really type inference? If it really was, you'd have to disallow chaining method calls, or using method calls inline as parameters to other method
by chowells 7y ago
Is the problem really type inference? If it really was, you'd have to disallow chaining method calls, or using method calls inline as parameters to other methods. Every intermediate value would need to have its type annotated explicitly, not just named values.
I don't think that's an improvement. Languages like Java and C++ don't work that way, and they're the ones being decried for having to spend too much time writing out redundant types.
I think the problem is that people don't treat types as documentation. List them explicitly when it clarifies. When it doesn't, leave them out. A lack of documentation is better than useless documentation. Treat types the exact same way.
- azhenley 7y ago“Local variable type inference” is a bit unwieldy of a term. Your conclusion is the same as mine. Use them when appropriate. When is appropriate? We need some data on that.
- maxxxxx 7y agoThis is highly personal. Best would be to have an IDE that shows the concrete types if desired by the user. In VS you can hover over a variable but permanent display would be nice too
- azhenley 7y agoRunning experiments would give us data on whether it is personal or not, and to what degree. I know a lot of teams that conduct code reviews outside of the IDE, so your suggestion wouldn’t help those cases.
- insertnickname 7y agoIntelliJ shows hints for inferred types.
- Quekid5 7y agoAs a data point: I use Scala + IntelliJ and I've personally actually turned this off. If you have a half-way decent type system I tend to find that it just gets in the way -- at least if things have reasonable names. (This is obviously a very personal preference and depends on whether it's a code base you're already familiar with, etc. etc.)
- Quekid5 7y agoWhile I agree with the desire for experimental data, you're assuming that the status quo[1] is the right answer. There's no evidence that it is -- the reason it wasn't mainstream until recently was mainly fear of going against the status quo. ML and Haskell, for example, have basically had (local and hear-global) type inference since the 1980s. [1] As of, say, 2009 or so where even local type inference was relatively rare in mainstream languages.
- ErotemeObelus 7y ago> A lack of documentation is better than useless documentation. Err.. I think it's the other way around.
- jcelerier 7y agoI don't think so. Useless documentation only wastes your time.
- b_t_s 7y agoand then there's counterproductive documentation. It may have been correct at one time, but now it both both wastes your time and misleads you. This is why pushing as much documentation as possible into the type system is a win.
- jcelerier 7y ago> Languages like Java and C++ don't work that way, and they're the ones being decried for having to spend too much time writing out redundant types. and yet as soon as you introduce auto you've got the mob bringing out the pitchforks :-)
- SloopJon 7y agoTIL that Java 10 added local-variable type inference, to which I say, about damn time. I indeed decry having to type (and read) Foo<Bar> baz = new Foo<Bar>(), and no, Foo<Bar> baz = new Foo<>() isn't much better. I tested a project a couple of years ago using Java 8, and the contrast with the magical inferential powers of lambdas was stark. Maybe it's because I've spent so much time in dynamically typed languages, but I see var/auto as absolutely essential to making static typing palatable. I'm a big fan of static typing, but I would be much less so if I had to do it without inference/deduction.
- java-man 7y agoyou obviously never refactored/debugged an old and massive code base written by people of various competency level...
- UIZealot 7y agoI just can't get over how dumb this is in Java: List<String> names = new List<String>(); Why not let people write just: List<String> names = new List(); Why did they even need to invent the diamond operator?