3 ms·

>A var in a data class constructor Just because you can, doesn't mean you should. I can count on one hand the number of data classes with vars in our codebase

>A var in a data class constructor Just because you can, doesn't mean you should. I can count on one hand the number of data classes with vars in our codebase of 500k+LOC, and they are specialized implementations for processes that would otherwise entail lots of copying and awful performance, whereas mutation just works.

pron 4y ago
That is the exact observation I was referring to! You can make that desired behaviour into a guarantee that the runtime and any other code can rely on without giving up much. So even though most data classes could be records, the construct still doesn't make the necessary guarantees. Because those times where data objects require mutation are not numerous, the benefit of reducing their syntax is small. So Java was able to give the syntax benefits in almost all of the same cases, and additionally it was able to make powerful behaviour guarantees.
- Tainnor 4y ago
  If you follow that logic to its conclusion, it means that you should just replace your Java code with Haskell (or at least OCaml). These are fine languages, but Kotlin is known to be more pragmatic. There are some footguns, make sure to be aware of them.
  - pron 4y ago
    OCaml and Haskell are very different; OCaml is much closer to Java than it is to Haskell. Java is, or soon will be, a nominally-typed ML-ish (which isn't saying all that much given how many languages were inspired by ML). You could say that one difference between Haskell and OCaml/Java is that OCaml and Java have algebraic data types, while Haskell has only algebraic data types. The only way my logic could lead to the conclusion that the Haskell approach is always advisable is if you mistake "ADTs are very useful" to mean "anything beyond ADTs is harmful", which is something that Java or OCaml don't say.
    - Tainnor 4y ago
      > Java is, or soon will be, a nominally-typed ML-ish (which isn't saying all that much given how many languages were inspired by ML). Sorry, but I call bullshit. As long as reflection is a huge part of major frameworks, libraries are loaded at runtime and mutability is the default for basically everything... there's just a world of difference between the two.
      - pron 4y ago
        I'll give you mutability by default, but I don't see why dynamic linking and reflection matter all that much (parametricity is not celebrated by the MLs as much as it is in Haskell). I think that the biggest fundamental difference between ML and Java is that ML's type system is primarily structural while Java's type system is primarily nominal. That's why I certainly wouldn't say Java is an ML (not even as much as Clojure is a Lisp), only that, like many other languages, it's ML-ish. It is no accident that virtually all of Java's biggest language features added since 1.0 -- generics, lambdas, ADTs, and pattern-matching -- were directly inspired by ML (although Java, which seeks to be a last mover, usually waits for several languages to adopt a feature before considering it).

pron 4y ago

That is the exact observation I was referring to! You can make that desired behaviour into a guarantee that the runtime and any other code can rely on without giving up much. So even though most data classes could be records, the construct still doesn't make the necessary guarantees. Because those times where data objects require mutation are not numerous, the benefit of reducing their syntax is small. So Java was able to give the syntax benefits in almost all of the same cases, and additionally it was able to make powerful behaviour guarantees.

Tainnor 4y ago
If you follow that logic to its conclusion, it means that you should just replace your Java code with Haskell (or at least OCaml). These are fine languages, but Kotlin is known to be more pragmatic. There are some footguns, make sure to be aware of them.
- pron 4y ago
  OCaml and Haskell are very different; OCaml is much closer to Java than it is to Haskell. Java is, or soon will be, a nominally-typed ML-ish (which isn't saying all that much given how many languages were inspired by ML). You could say that one difference between Haskell and OCaml/Java is that OCaml and Java have algebraic data types, while Haskell has only algebraic data types. The only way my logic could lead to the conclusion that the Haskell approach is always advisable is if you mistake "ADTs are very useful" to mean "anything beyond ADTs is harmful", which is something that Java or OCaml don't say.
  - Tainnor 4y ago
    > Java is, or soon will be, a nominally-typed ML-ish (which isn't saying all that much given how many languages were inspired by ML). Sorry, but I call bullshit. As long as reflection is a huge part of major frameworks, libraries are loaded at runtime and mutability is the default for basically everything... there's just a world of difference between the two.
    - pron 4y ago
      I'll give you mutability by default, but I don't see why dynamic linking and reflection matter all that much (parametricity is not celebrated by the MLs as much as it is in Haskell). I think that the biggest fundamental difference between ML and Java is that ML's type system is primarily structural while Java's type system is primarily nominal. That's why I certainly wouldn't say Java is an ML (not even as much as Clojure is a Lisp), only that, like many other languages, it's ML-ish. It is no accident that virtually all of Java's biggest language features added since 1.0 -- generics, lambdas, ADTs, and pattern-matching -- were directly inspired by ML (although Java, which seeks to be a last mover, usually waits for several languages to adopt a feature before considering it).