81–90 of 132 posts
But I'm glad it's just for initializers.
After playing with Scala, I've found out I don't love type inference as much as I thought I did. In Scala, the compiler can infer return types of named procedures for example, but I've always found omitting these makes my code harder to read, having to read the body (an implementation detail) to see what it may be returning. It would be even worse if types were optional for parameters (ala Haskell). Other modern languages (ala Rust) have come to realization that this is a bad idea.
The same even applies to having the compiler infer types from local variables to a lesser extent. A lot of my code goes through transformations and chains, and sometimes it's not obvious what the resulting type is (and what the code is doing) if the type is not specified.
Even looking at the simple example mentioned from the article in isolation:
var stream = list.stream();
The same issue applies with calling functions and assiging their result to a local variable you're initializing.
I'm happy to see type inference is just added for initializers. Whilst I haven't found writing 'Foo foo = new Foo()' that common in functional code, I see that being prevalent in Java at least. On the flip side though, if your language or use case (C++?) makes code harder to understand rather than easier by specifying types, then you may be wishing you had type inference :)
Having the option to use type inference in this specific use case is nice. But I'm glad it's just for initializers. After playing with Scala, I've found out I don't love type inference as much as I thought I did. In Scala, the compiler can infer return types of named procedures for example, but I've always found omitting these makes my code harder to read, having to read the body (an implementation detail) to see wha…
The Haskell community seems pretty well agreed that top level declarations should have type annotations (arguments and return values) in code that's going to be maintained. With -Wall, GHC will even give you warnings about top level declarations without types. No reason to require it for quick (~5 min) experimental hackary or one-off scripting - in that case, add it if it helps and omit it if it doesn't, and the ability to ask what the compiler thinks the type is can come in handy as well.
Having the option to use type inference in this specific use case is nice. But I'm glad it's just for initializers. After playing with Scala, I've found out I don't love type inference as much as I thought I did. In Scala, the compiler can infer return types of named procedures for example, but I've always found omitting these makes my code harder to read, having to read the body (an implementation detail) to see wha…
> It would be even worse if types were optional for parameters (ala Haskell). The Haskell community seems pretty well agreed that top level declarations should have type annotations (arguments and return values) in code that's going to be maintained. With -Wall, GHC will even give you warnings about top level declarations without types. No reason to require it for quick (~5 min) experimental hackary or one-off script…
I think deciding what to allow and prohibit by default is an important design decision.
Earlier quoted context omitted.
> It would be even worse if types were optional for parameters (ala Haskell). The Haskell community seems pretty well agreed that top level declarations should have type annotations (arguments and return values) in code that's going to be maintained. With -Wall, GHC will even give you warnings about top level declarations without types. No reason to require it for quick (~5 min) experimental hackary or one-off script…
Seems reasonable. But now you risk the chance of reading code written by those who don't specify types, don't know better, or don't use -Wall. I think deciding what to allow and prohibit by default is an important design decision.
I don't think I disagree with that, but I don't think it was made wrong here. It's true that you "risk the chance" of reading unannotated code, but I find there are times when the code I need to write is clearer to me than the type it'll have, and being able to defer annotation past compilation is occasionally a big win and often a small one.
And in that worst case scenario of having to look at unannotated code, you can fall back to asking your tooling.
Earlier quoted context omitted.
Yeah, let's spread the nonsense further! There are constants and variables; values are something else. Just because "val" is a short abbreviation everybody gets, it doesn't mean we should abuse it!
I disagree with that sentiment. Constant to me implies decided at compile time. The reason we should use "val" is because it is a short abbreviation everybody gets. It also has symmetry with "var," as "value" and "variable" are both adjectives, whereas "let" is a verb.
And every time I see 'var', I cringe because I don't know if they mean variable or variant. But 'val' is just usless. Variables evaluate to values, constants evaluate to values, expressions are values, first-class functions are values... Everything is val.
Earlier quoted context omitted.
Seems reasonable. But now you risk the chance of reading code written by those who don't specify types, don't know better, or don't use -Wall. I think deciding what to allow and prohibit by default is an important design decision.
> I think deciding what to allow and prohibit by default is an important design decision. I don't think I disagree with that, but I don't think it was made wrong here. It's true that you "risk the chance" of reading unannotated code, but I find there are times when the code I need to write is clearer to me than the type it'll have, and being able to defer annotation past compilation is occasionally a big win and ofte…
I often wish I was using a text editor or IDE that understood my code and could insert type annotations for me, maybe automatically, and maybe not choose to do so if the line of code would "look" more redundant (i.e: parsing variable name or constructor/initializer).
Rust is one language that, while has the capability of doing full type inference, deliberately chose not to (https://doc.rust-lang.org/book/functions.html):
> This is a deliberate design decision. While full-program inference is possible, languages which have it, like Haskell, often suggest that documenting your types explicitly is a best-practice. We agree that forcing functions to declare types while allowing for inference inside of function bodies is a wonderful sweet spot between full inference and no inference
I hope this gets added to the language, we use Lombok heavily where I work and find it pretty great with it's val class that allows type inference, although it requires an explicit import and can't be used within Lambdas. The website isn't the prettiest but Lombok is a fantastic addition to a Java codebase and massively reduces the amount of boiler plate often associated with Java. A list of Lombok features https://p…
This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…
> Regarding val vs let I like the approach mentioned of just reusing final for immutability.