6 ms·

Java's stance is flat wrong as a matter of practice. I don't believe I've once had the compiler infer a wrong type in a way that led to runtime bugs. If it did,

Java's stance is flat wrong as a matter of practice. I don't believe I've once had the compiler infer a wrong type in a way that led to runtime bugs. If it did, we would all be rightfully annoyed with that compiler because it would be broken. Once more, for the back of the room: Java does not count as an example of a worthwhile type system. Good types do not increase verbosity.

didibus 6y ago
I can see you disagree on a matter of principle and personal experience. And that's alright. I just think it's as valid an opinion as all the others. There are some who like explicitly defined types of various levels. Those who want it all infered or partially infered, and those who don't want them at all, or want them optional or gradual, etc. And none has been able to make a claim over the others even now years later the debate still rage on. The data doesn't show up. And different people have different experience that leads them to different paths. So I like to think of it more as a personal choice. Like various master chef all have their preferred brand and type of knife, so do developers with programming language and type checkers.
- andrewflnr 6y ago
  Any language that supports type inference will also support annotations if your taste/linter/boss demands it. That's fine. But hobbling the compiler by not including type inference at all, because you think it causes bugs, is quite definitely stupid. I literally don't understand how anyone could dispute this except by inexperience with type inference. Based on the sentence with the tangent about "optional or gradual" etc, I suspect you are conflating two debates. Of course there is debate on to what degree static type systems are helpful. That is quite separate from the debating whether to include the very convenient and theoretically rock-solid feature of type inference. I have hardly heard anyone discuss this, much less attempt to gather empirical data. Returning to the original point, there is no conflict between static typing and concision, except in C++/Java style type systems. I especially don't understand how a "static type checker enthusiast" would think there is, but if you meet one tell them Someone On The Internet told them to learn OCaml already.
  - didibus 6y ago
    Did you follow the link I provided? Like I said, I'm definitely pro inference, in fact, I don't even mind a dynamic language (depending which one), give me a Lisp or Smalltalk and I don't even need any static type checking. Now, OCaml is actually next on my list, but I've done Rust, Haskell and Elm, used Kotlin, Scala, Fantom, and C#. And I've used core.typed on Clojure, for now, Clojure is my language of choice, but I definitely like a functional language with a fully infered type system compared to the imperative flavours. But there is a segment of the static checking world which is dedicated to non Hindley-Milner, mostly imperative, mostly OO scene, and I feel denying Java's influence on static typing I think would be reductionary, as it is one of the most widely used statically typed language. Anyways, I just wanted to bring their voice to the conversation, even if I don't agree, and am a big fan of local type inference that Java 10 added. Which maybe the fact that they finally added it shows they recon being wrong about it. Now, for cause of error. One of the one they describe is "action at a distance" like this: var result; // many lines of code result = new ArrayList<String>(); Now here because the assignment could be way later in the code, someone might mistake the type of the variable since it isn't obvious what it would be,.since the assignment is so far away from the declaration. Another issue they talked about was multiple assignment. For example: var x = "Hello" // multiple lines later x = new CustomerName(); Now what should the type of x be? Java could infer that it must be the closest common ancestor, which might be Object in this case. That's most likely not correct though, and the rest of the type checking now will probably lead to weird errors. Like why doesn't x work with String methods or CustomerName methods? Another issue is with ABI compatibility. If the return type of a method is infered, and compiled. And a dependent class uses it. A programmer could change the implementation and have the inference infer a compatible but different type all of a sudden, like say it now infers ArrayList instead of the interface type List. Now the client code is broken, because it assumed the List type, and this is probably not the intent of the programmer, but a side effect of the inference having changed without their notice. I think they talk about more stuff here. You got to dig into the mailing lists and JEPs and all to find most of it.
    - andrewflnr 6y ago
      I'm not trying to deny Java's influence, just saying that it's bad. I do think it was worth bringing up (I upvoted your top-level comment), but mostly because we need to recognize the damage it has caused to the discussion around typing. People try to talk about "dynamic vs static", or worse run studies, when their only static language is Java. Their arguments are nonsense and their studies are wasted as far as I'm concerned, since they're dealing with a straw man. Java is treated as the poster child when it should be the black sheep. FFS, it still has null pointers. Your examples are mostly not problems in reasonable languages. Just don't declare variables before initialization. Assigning a variable two incompatible types is an error, just like it would be without inference. I'll grant the ABI one is interesting. In situations where separate compilation is on the table, maybe you want to annotate function types. But obviously the myriad of inferred languages don't suffer much from this. You could just as reasonably argue that the class author made a breaking change, and it should be treated exactly as if they changed the annotation.

didibus 6y ago

I can see you disagree on a matter of principle and personal experience. And that's alright. I just think it's as valid an opinion as all the others. There are some who like explicitly defined types of various levels. Those who want it all infered or partially infered, and those who don't want them at all, or want them optional or gradual, etc. And none has been able to make a claim over the others even now years later the debate still rage on. The data doesn't show up. And different people have different experience that leads them to different paths. So I like to think of it more as a personal choice. Like various master chef all have their preferred brand and type of knife, so do developers with programming language and type checkers.

andrewflnr 6y ago
Any language that supports type inference will also support annotations if your taste/linter/boss demands it. That's fine. But hobbling the compiler by not including type inference at all, because you think it causes bugs, is quite definitely stupid. I literally don't understand how anyone could dispute this except by inexperience with type inference. Based on the sentence with the tangent about "optional or gradual" etc, I suspect you are conflating two debates. Of course there is debate on to what degree static type systems are helpful. That is quite separate from the debating whether to include the very convenient and theoretically rock-solid feature of type inference. I have hardly heard anyone discuss this, much less attempt to gather empirical data. Returning to the original point, there is no conflict between static typing and concision, except in C++/Java style type systems. I especially don't understand how a "static type checker enthusiast" would think there is, but if you meet one tell them Someone On The Internet told them to learn OCaml already.
- didibus 6y ago
  Did you follow the link I provided? Like I said, I'm definitely pro inference, in fact, I don't even mind a dynamic language (depending which one), give me a Lisp or Smalltalk and I don't even need any static type checking. Now, OCaml is actually next on my list, but I've done Rust, Haskell and Elm, used Kotlin, Scala, Fantom, and C#. And I've used core.typed on Clojure, for now, Clojure is my language of choice, but I definitely like a functional language with a fully infered type system compared to the imperative flavours. But there is a segment of the static checking world which is dedicated to non Hindley-Milner, mostly imperative, mostly OO scene, and I feel denying Java's influence on static typing I think would be reductionary, as it is one of the most widely used statically typed language. Anyways, I just wanted to bring their voice to the conversation, even if I don't agree, and am a big fan of local type inference that Java 10 added. Which maybe the fact that they finally added it shows they recon being wrong about it. Now, for cause of error. One of the one they describe is "action at a distance" like this: var result; // many lines of code result = new ArrayList<String>(); Now here because the assignment could be way later in the code, someone might mistake the type of the variable since it isn't obvious what it would be,.since the assignment is so far away from the declaration. Another issue they talked about was multiple assignment. For example: var x = "Hello" // multiple lines later x = new CustomerName(); Now what should the type of x be? Java could infer that it must be the closest common ancestor, which might be Object in this case. That's most likely not correct though, and the rest of the type checking now will probably lead to weird errors. Like why doesn't x work with String methods or CustomerName methods? Another issue is with ABI compatibility. If the return type of a method is infered, and compiled. And a dependent class uses it. A programmer could change the implementation and have the inference infer a compatible but different type all of a sudden, like say it now infers ArrayList instead of the interface type List. Now the client code is broken, because it assumed the List type, and this is probably not the intent of the programmer, but a side effect of the inference having changed without their notice. I think they talk about more stuff here. You got to dig into the mailing lists and JEPs and all to find most of it.
  - andrewflnr 6y ago
    I'm not trying to deny Java's influence, just saying that it's bad. I do think it was worth bringing up (I upvoted your top-level comment), but mostly because we need to recognize the damage it has caused to the discussion around typing. People try to talk about "dynamic vs static", or worse run studies, when their only static language is Java. Their arguments are nonsense and their studies are wasted as far as I'm concerned, since they're dealing with a straw man. Java is treated as the poster child when it should be the black sheep. FFS, it still has null pointers. Your examples are mostly not problems in reasonable languages. Just don't declare variables before initialization. Assigning a variable two incompatible types is an error, just like it would be without inference. I'll grant the ABI one is interesting. In situations where separate compilation is on the table, maybe you want to annotate function types. But obviously the myriad of inferred languages don't suffer much from this. You could just as reasonably argue that the class author made a breaking change, and it should be treated exactly as if they changed the annotation.