Live data from Hacker News

In Java 3 = 12

virtualspecies.com

41–50 of 55 posts

Re: In Java 3 = 12

#41

This isn't at all surprising if you know how Java works; you could probably point out this kind of a strange feature case in nearly any language if you look hard enough. It does left to right order of operands, so 1 + 2 happens as integer addition since both operands are integers, then + "=" does string concatenation since one of the operands is a String, then "3=" + 1 evaluates as a concatenation since one of the op…

> you could probably point out this kind of a strange feature case in nearly any language if you look hard enough

I disagree. I think it's a product of bad language design.

Re: In Java 3 = 12

#42

I really don't think this should be confusing - having a decent grasp on associativity and precedence is a pretty useful skill - so for example understanding WHY println(3 * 2 + "-" + 6 * 3) behaves "differently" is something I'd hope people would get. And let's be honest, you definitely don't want to 'fix' this by tweaking precedence to include types. That way madness lies. ;) Definite shout to ubernostrum's commmen…

I think + for append is fine, it certainly seems to make sense to me that you get "helloworld" from "hello"+"world".

I think the confusing thing is the type coercion. Does it make sense that "2"+3 is "23" but 2+"3" is not 5?

    (3*4).toString() + "=" + 3.toString() + 4.toString())
would not be as surprising that the two sides are different.

Re: In Java 3 = 12

#43
I had to look twice at this. I was surprised that I could add the string “=“ to ‘3’. I guess what’s happening here is the int gets boxed and then gets implicitly converted to String. Proof of the pudding would be to try it with a simple string assignment rather than System.out.println. What happens after the “=“ is more straightforward

Re: In Java 3 = 12

#45
post #27

Earlier quoted context omitted.

Thanks for that explanation. So Java is weakly typed? Or would you say less strongly typed? Is the strength determined by the amount of implicit type coercions that are available? Does static vs dynamic also imply that the strong-ness is checked at compile vs runtime? In other words, in python this bug can lurk undetected in your code list = (1, 2, 3) ‎x = list + 1 while in Java it will throw the error at compile tim…

> In other words, in python this bug can lurk undetected in your code Well, if you use Python 3 and a modern editor, you will get a big red warning. mypy has been able to check types for a while and a lot of editors embed it.

But mypy is basically a static type checker for python. So my point still stands that static implies that strong-ness is checked at compile time, or IDE time in this case.

Thinking about this more, if all that strong vs weak is referring to is implicit type coercions then it is a useless confusing term. Static vs dynamic refers to when the type checking occurs, implicit type coercions are just one of the things the type checker looks for.

Re: In Java 3 = 12

#46
post #27

Earlier quoted context omitted.

dynamic vs. static typing is independent of strong vs. weak typing. strong typing is basically allowing fewer implicit converstations, weak more. static means type checking happens before runtime, dynamic means the opposite.

Thanks for that explanation. So Java is weakly typed? Or would you say less strongly typed? Is the strength determined by the amount of implicit type coercions that are available? Does static vs dynamic also imply that the strong-ness is checked at compile vs runtime? In other words, in python this bug can lurk undetected in your code list = (1, 2, 3) ‎x = list + 1 while in Java it will throw the error at compile tim…

> Does static vs dynamic also imply that the strong-ness is checked at compile vs runtime?

It's less like "implies" and more like "it's the definition of".

Re: In Java 3 = 12

#47
post #8

Earlier quoted context omitted.

Yes but that's strange. Java is such a staticaly typed language you would not expect it to do that if you are like me and don't know it very well. While Python is very dynamic, but: >>> print(1 + 2 + "=" + 1 + 2) Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str'

dynamic vs. static typing is independent of strong vs. weak typing. strong typing is basically allowing fewer implicit converstations, weak more. static means type checking happens before runtime, dynamic means the opposite.

Strong vs weak typing also means whether you can circumvent the type system. So C/C++ are weakly typed systems because the laws of types are more like guidelines there and you can cast around them to reinterpret memory contents.

Re: In Java 3 = 12

#48
post #41

This isn't at all surprising if you know how Java works; you could probably point out this kind of a strange feature case in nearly any language if you look hard enough. It does left to right order of operands, so 1 + 2 happens as integer addition since both operands are integers, then + "=" does string concatenation since one of the operands is a String, then "3=" + 1 evaluates as a concatenation since one of the op…

> you could probably point out this kind of a strange feature case in nearly any language if you look hard enough I disagree. I think it's a product of bad language design.

The bad design here is having implicit type conversion at all. The few characters you save with this rarely used feature are not worth the potential confusion. But it is a trade-off, Java is normally criticized in the other direction, for forcing you to be overly explicit.

Re: In Java 3 = 12

#49
post #41

This isn't at all surprising if you know how Java works; you could probably point out this kind of a strange feature case in nearly any language if you look hard enough. It does left to right order of operands, so 1 + 2 happens as integer addition since both operands are integers, then + "=" does string concatenation since one of the operands is a String, then "3=" + 1 evaluates as a concatenation since one of the op…

> you could probably point out this kind of a strange feature case in nearly any language if you look hard enough I disagree. I think it's a product of bad language design.

I disagree. I am not an expert of java language subtleties, but I had no problem to predict and explain this output. I think it is a product of the language simplicity. I have a deeper knowledge of C and more experience, but I regularly fail to predict output in similar exercises.

Re: In Java 3 = 12

#50

1 + 2 + "=" + (1 + 2)

Or as one might write in real life:

  (1 + 2) + "=" + (1 + 2)
A few braces here and there are a very practical substitute to wasting brain cycle about subtleties in operator precedence and associativity.
Post reply on HN