Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Representing the Impractical and Impossible with JDK 10 “var”

benjiweber.co.uk

Post reply on HN
Print view View original

51–60 of 131 posts

Re: Representing the Impractical and Impossible with JDK 10 “var”

#51

Post by Someone »

koolba wrote: post #23
pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Any sufficiently sharp tool can cut deeply in the hands of the untrained. The answer isn't to dullen our blades, it's to find better apprentices and journeyman to work with.

The answer also is to have safety features. A chainsaw has to be sharp, but also has to have a chain catcher, kickback protection, etc.

I don’t think requiring programmers to always write out the type of a variable on every declaration is such a feature, but can see arguments for requiring them in some places where compiler could infer them. Types of function arguments in function declarations are an example.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#52

Post by Amelorate »

akerro wrote: post #40
pents90 wrote: post #2

While I submitted this, I would like to voice my opinion that I am against "var" in Java. People may ask, "Why should I have to enter in the type if the compiler can infer it for me?" My answer is twofold: 1) You or some other maintainer will need to know what that type is later when reading the code. Of course, "var" is meaningless, requiring you to dig back one or more steps to determine the actual type. 2) You don…

Well, I don't like streams in Java, they make code much slower, it looks fancies, but in real time, streams are often abused and make code run longer in almost every case I measured (I took some methods from Github, SO and reddit comments). Equivalent for loop/for-iterator loop is much faster. Solution: you don't have to use it, you can educate others how to use it properly.

It is possible for a compiler to optimize long method chains into the equivalent imperative code. The rust compiler is an example, and in the case of the iterator trait, it can actually be optimized better than the equivalent imperative code, by removing checks when indexing into the array.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#54

Post by DonHopkins »

Thiez wrote: post #47
seanmcdirmid wrote: post #27

Earlier quoted context omitted.

There is no appreciable performance hit for locally inferred types given that the compiler isn’t doing much. Globally inferred types can take a hit, though most of those are based on Hindley Milner which can be pretty efficient.

If the suggested `var` is anything like that of c#, there is no performance hit. When you type `Type t = some.expression()`, the compiler has to perform type inference on `some.expression()` anyway , otherwise it wouldn't be able to tell you when you've declared the type of `t` incorrectly. Indeed, when you write the wrong type there, the error message will actually tell you what type was inferred.

It reminds me of one of Bertrand Myer's many criticisms of C++ that I read in his book on Eiffel. (Almost every page of his book made fun of C++ in some way -- it was a delightful read!)

He pointed out that there was no reason for C++ to have both "." and "->", because the compiler always knew which one was required, and it only gave the programmer the opportunity to make a mistake, and a lot of extra effort changing every line of code if you change your mind about whether to use a pointer or not.

The definition of whether a member is a pointer or an inlined struct/object should only be one place in the code: in the class declaration, not scattered around every line of code in the program that uses it.

C++'s excuse was that it was trying to be compatible with C. Of course Java side-stepped the problem by not supporting embedded structs, but C# got it right.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#55

Post by Thiez »

Amelorate wrote: post #52
akerro wrote: post #40

Earlier quoted context omitted.

Well, I don't like streams in Java, they make code much slower, it looks fancies, but in real time, streams are often abused and make code run longer in almost every case I measured (I took some methods from Github, SO and reddit comments). Equivalent for loop/for-iterator loop is much faster. Solution: you don't have to use it, you can educate others how to use it properly.

It is possible for a compiler to optimize long method chains into the equivalent imperative code. The rust compiler is an example, and in the case of the iterator trait, it can actually be optimized better than the equivalent imperative code, by removing checks when indexing into the array.

The default Java compiler doesn't do much optimizing. This is intentional, so there would be incentive to make the JVM really smart (a great decision, I think). But it's possible that the JVM doesn't optimize streams that well at this time.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#56

Post by MichaelGG »

ajkjk wrote: post #37
lkjlakjsdlfkj wrote: post #14

"let" is more elegant IMO.

I always found 'let' to be such a strange name. What on earth is appealing about it? The usual variable declaration syntax is ; it's not a stretch to imagine the type as 'var', a catchall type. But 'let'? Let is a verb; it should be in a place where functions, not types, go. It makes sense in "let x in {}" type expressions, and it kinda makes sense in Lisp, but I don't see any argument for it in a C-like language.

>It makes sense in "let x in {}" type expressions

Without jumps, all code can be rewritten to be a series of "let x = ... in "

The fact Java has statements instead of everything being expressions is a design flaw and should be rectified not glorified.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#57

Post by threeseed »

vbezhenar wrote: post #24

I'm very disappointed that they didn't make `val` keyword. Very simple change but code becomes significantly more readable and a lot of bugs will be compile errors.

Java is not Scala though.

By default everything has always been mutable e.g. collections, variables. And so whilst I support val I can appreciate the difficulty in switching everyone to an immutable by default mindset. Especially given the lack of decent functional transforms e.g. map, flatMap, filter in Java.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#58

Post by trixie_ »

Amelorate wrote: post #50
trixie_ wrote: post #16

Earlier quoted context omitted.

I'm pro var * I write code a lot more fluidly with var. When I go back to writing non-var code (enforced by some departments) I find that it breaks my focus on solving the problem at hand. I end up writing my code with var and then going back and replacing my vars with the type names. * I find code a lot easier to read. I can understand the flow of the logic easier, the variable names are enough. Unless you have the…

Counter-argument to changing the return type of a function with var: You can change the return type of the function to another type that might break some assumptions later in the code. For example, if the code assumes it has a type Foo with a length field, and you change the return type of tha function to a Bar without that length field, the compiler will complain that Bar doesn't have a length field, rather than com…

I mentioned the first case in my post - using var is better because there’s minimal code change when refactoring and the compiler will tell you any incompatibilities to look into.

For the second case, var or not, it doesn’t matter. If you’re changing the meaning of a property it’s common sense to ‘find all refernces’ and review where that property is used.

Re: Representing the Impractical and Impossible with JDK 10 “var”

#59

Post by bitwize »

extrememacaroni wrote: post #10
arcticbull wrote: post #8

Earlier quoted context omitted.

I'd suggest that means your `getAddress()` name could be improved to convey the necessary information.

`getAddressWhichIsOfTypeString()`? `str_GetAddress()`? `GetAddress_STR()`?

getAddressAsString()

getAddress().toString()

Re: Representing the Impractical and Impossible with JDK 10 “var”

#60

Post by adrianmonk »

Insanity wrote: post #29

It's one of the things I really missed when going from C# to Java, but with IntelliJ, the typing experience is very similar from C#. Imagine I want to have a variable like: Person p = new Person("John"); All I would type in IntelliJ is: new Person("John").var After pressing "tab", that will autocomplete for me and put the focus on the variable name so I can rename it from the default inferred value.

Don't most decent IDEs support something like that? In Eclipse you can just type

    new Person("John")
And then hit Ctrl-2 L.
Post reply on HN