Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hmm... I agree it looks nicer.

Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing.

It's also nice to be able to go the declaration of a variable to see exactly what type it is - that's mostly for code not written by myself, or old code that I do not remember. For local variable that's fine (I hope we won't infer types this way for method parameters), so I guess I like it there.



> Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing.

Reducing boilerplate mostly helps with reading code, not with writing it.


It does, my code and trail of thought is significantly different when switching to coffeescript from javascript.


> Who's typing Java code all by hand these days, though? > There various IDEs that save me all the typing.

Some truth in that, it should be safe enough to assume that the lightweight editor crowd has long self-selected out of java. I often do write-time type inference by declaring anything as an int and then, at the end of the line, pressing whatever magic key that makes the IDE rewrite it to the actual type so that it compiles.

One of the syntax options in the JEP is "final name = RHS;". When i first saw that i could not understand why anybody in their right mind would even consider a partial solution like that. But now that i wrote about write-time type inference, it starts getting more and more attractive:

A tiny nudge towards immutability, natural "write-time type inference" that is correct until the first nonfinal access is written (IDEs already offer a "make nonfinal?" fix in that case) and nonfinal identifiers will often be a broader type than the RHS assignment anyway.


>>I hope we won't infer types this way for method parameters

No, it doesn't. From TFA: "This treatment would be restricted to local variables with initializers, indexes in the enhanced for-loop, and locals declared in a traditional for-loop; it would not be available for method formals, constructor formals, method return types, fields, catch formals, or any other kind of variable declaration."

Which is pretty much how C# does it.

I gather that it's common for functional languages to infer pretty much everything for you most of the time, which I think would actually be nice. But presumably that's either difficult or impossible in Java.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: