6 ms·

Appreciate Kotlin and others pushing it there.

by rcaught 2y ago

kaba0 2y ago
Yeah, the ant pushing the elephant..
- marginalia_nu 2y ago
  Java's stated design philosophy since way back is to let other languages experiment and then incorporate what appears to work out, thus being able to maintain an append-only change philosophy where everything is always backwards compatible. Kotlin is undeniably a source of inspiration, as is many other languages. (This doesn't always work out, some bad API decisions[1] will likely haunt Java forever, some features are arguably a bit undercooked (e.g. exception handling in Stream:s), but given the constraints it's kind of remarkable how well it does work) [1] https://stackoverflow.com/questions/21410683/boolean-getbooleantrue-returns-false https://stackoverflow.com/questions/21410683/boolean-getbool...
  - kaba0 2y ago
    That’s true. But why would Java take inspiration from Kotlin, which adds very little new to the picture (scala has done basically everything before, let alone ML, from where most of the new features java (or any other modern language) copies originate from)
    - deleted 2y ago
      [deleted]
  - vbezhenar 2y ago
    Checked exceptions themselves to me looks like an experiment which had no place in Java. I don't know language landscape in 1990, may be it looked like a good idea back then. But today: C++, JavaScript, Python, C# are few of the most popular languages which use unchecked exceptions. May be one day Java will just retire this concept and make all exceptions unchecked. It'll be backwards-compatible change. Make `throws` clause cause deprecation warnings and that's about it.
    - lolinder 2y ago
      Checked exceptions are an unfortunate case of a feature being rolled out in a language that wasn't ready to support it ergonomically and then becoming a pariah because of how bad the experience was in that language. There's nothing wrong with the concept—checked exceptions are conceptually the same as every function returning a Result type—but without type inference and without some ergonomics like Rust's ? operator they're really hard to work with and so people grew to hate them. I personally believe that it is now within reach for Java to fix checked exceptions to be ergonomic and useful. If they do it, Java could have one of the best error handling paradigms out of any modern language, but I suspect it won't happen because the community has come to land so firmly against checked exceptions.
      - lenkite 2y ago
        Making big feature and possibly breaking changes such as making checked exceptions ergonomic would only be possible if the original language designer - James Gosling decided to dust his sleeves, un-retire himself and lead the job. Now, its a distant pipe dream.
halfmatthalfcat 2y ago
Scala, especially
The_Colonel 2y ago
Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases. JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.
- wh0knows 2y ago
  If you properly handle not returning/using nulls in your checkstyle rules and don’t allow nulls to be deserialized anywhere (forcing the use of Optional), then you can pretty much eliminate NPE. I can’t remember the last time I encountered one by using the proper compile time checks. It does need to be enforced organization-wide, and not partially with annotations, but if you can make that change then you can code in Java without the mental overhead of null.
  - lolinder 2y ago
    What about the standard library? What about other libraries that you depend on? Can't those introduce NPEs?
    - wh0knows 2y ago
      Inputs to standard libraries will obviously never NPE if you pass in a non-null value. For outputs, a lot of standard collection .get() calls are unnecessary when you’re working with small collections or Optionals, where you simply use stream, filter, ifPresent. Or simply wrap the return with Optional.ofNullable, checkstyle will not accept it if you don’t.
  - mrkeen 2y ago
    > I can’t remember the last time I encountered one by using the proper compile time checks. When you're sufficiently careful, you can reduce accidental nulls down to the level of minor inconvenience. But no amount of care on your part will stop your teammates from deliberately using nulls.
    - 2y ago

Appreciate Kotlin and others pushing it there.

kaba0 2y ago

Yeah, the ant pushing the elephant..

marginalia_nu 2y ago
Java's stated design philosophy since way back is to let other languages experiment and then incorporate what appears to work out, thus being able to maintain an append-only change philosophy where everything is always backwards compatible. Kotlin is undeniably a source of inspiration, as is many other languages. (This doesn't always work out, some bad API decisions[1] will likely haunt Java forever, some features are arguably a bit undercooked (e.g. exception handling in Stream:s), but given the constraints it's kind of remarkable how well it does work) [1] https://stackoverflow.com/questions/21410683/boolean-getbooleantrue-returns-false https://stackoverflow.com/questions/21410683/boolean-getbool...
- kaba0 2y ago
  That’s true. But why would Java take inspiration from Kotlin, which adds very little new to the picture (scala has done basically everything before, let alone ML, from where most of the new features java (or any other modern language) copies originate from)
  - deleted 2y ago
    [deleted]
- vbezhenar 2y ago
  Checked exceptions themselves to me looks like an experiment which had no place in Java. I don't know language landscape in 1990, may be it looked like a good idea back then. But today: C++, JavaScript, Python, C# are few of the most popular languages which use unchecked exceptions. May be one day Java will just retire this concept and make all exceptions unchecked. It'll be backwards-compatible change. Make `throws` clause cause deprecation warnings and that's about it.
  - lolinder 2y ago
    Checked exceptions are an unfortunate case of a feature being rolled out in a language that wasn't ready to support it ergonomically and then becoming a pariah because of how bad the experience was in that language. There's nothing wrong with the concept—checked exceptions are conceptually the same as every function returning a Result type—but without type inference and without some ergonomics like Rust's ? operator they're really hard to work with and so people grew to hate them. I personally believe that it is now within reach for Java to fix checked exceptions to be ergonomic and useful. If they do it, Java could have one of the best error handling paradigms out of any modern language, but I suspect it won't happen because the community has come to land so firmly against checked exceptions.
    - lenkite 2y ago
      Making big feature and possibly breaking changes such as making checked exceptions ergonomic would only be possible if the original language designer - James Gosling decided to dust his sleeves, un-retire himself and lead the job. Now, its a distant pipe dream.

halfmatthalfcat 2y ago

Scala, especially

The_Colonel 2y ago

Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases. JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.

wh0knows 2y ago
If you properly handle not returning/using nulls in your checkstyle rules and don’t allow nulls to be deserialized anywhere (forcing the use of Optional), then you can pretty much eliminate NPE. I can’t remember the last time I encountered one by using the proper compile time checks. It does need to be enforced organization-wide, and not partially with annotations, but if you can make that change then you can code in Java without the mental overhead of null.
- lolinder 2y ago
  What about the standard library? What about other libraries that you depend on? Can't those introduce NPEs?
  - wh0knows 2y ago
    Inputs to standard libraries will obviously never NPE if you pass in a non-null value. For outputs, a lot of standard collection .get() calls are unnecessary when you’re working with small collections or Optionals, where you simply use stream, filter, ifPresent. Or simply wrap the return with Optional.ofNullable, checkstyle will not accept it if you don’t.
- mrkeen 2y ago
  > I can’t remember the last time I encountered one by using the proper compile time checks. When you're sufficiently careful, you can reduce accidental nulls down to the level of minor inconvenience. But no amount of care on your part will stop your teammates from deliberately using nulls.
  - 2y ago