4 ms·

Syntactic sugar does not solve programming problems. Kotlin does not offer any paradigm changes which could make switch worth it.

deleted 7y ago
[deleted]
vbezhenar 7y ago
The only Kotlin feature that it's really hard to live without is properties. Otherwise sure, it's better than Java 11, but I can live without all those niceties. And (non)nullable types even get in my way! I just don't understand where there's syntax sugar for propeties in Java. There are lot of unneeded stuff added, that I don't really care about. But my classes are still full of autogenerated getters/setters. I recently tried to find some JEP and I did not find one. There was some talk around Java 7, but nothing since that. Nobody even wants to add properties support for Java?
- sverhagen 7y ago
  And (non)nullable types even get in my way! Interesting how that goes...: the sibling comment to yours said the exact opposite. How does this feature get in your way?
  - vbezhenar 7y ago
    1. Language problem: if (this.prop != null) { this.prop.something() // does not work } this construction works for local variables, but not for properties. Yeah, theoretically it could be modified by another thread or function in the middle. In practice it does not happen and I'm forced to use terrible code like this.prop?.apply { prop -> prop.something() } (this example could be written as this.prop?.something() but that's not the point, usually it's harder than that. 2. Interoperation problem. A lot of Java code does not use @Nullable annotations, so all types are just that: platform types. So Kotlin nullability adds nothing to that.
    - aflag 7y ago
      What is uglier about the kotlin code? It's the same number of lines and the code is more robust. What's the ugly part?
      - vbezhenar 7y ago
        Using library functions instead of language keywords feels very wrong to me.
        aflag 7y ago
        Why?
- oweiler 7y ago
  Probably because in general they are a code smell. They are anti-OO.
  - vbezhenar 7y ago
    That's just not true. If I'm writing simplest REST service, I have to return JSON responses. To return JSON response, I have to write class corresponding to that response. And that will be data class. If I'm interacting with database, I'm writing data mapping classes. And that will be data class. Those are normal code that every developer writes every day. If you think that it's anti-OO, then I don't care about that OO. I care about writing performant, concise and extensible software.
    - ivan_gammel 7y ago
      That statement is valid in both contexts you mention. You do not need properties for data mapping and serialization - it’s possible to write a good OO code without getters and setters.
  - antisemiotic 7y ago
    If a useful feature is incompatible with OO, it's a problem with OO, not with the feature. Properties allow one to work with plain old data (not everything is meaningfully an object with behavior) without freezing the underlying implementation forever. Fewer (or maybe more decentralized) religious arguments like this is one of the few things I like about my job in C++. (Shame C++ doesn't have properties, these would come in handy in refactoring config handling code that I currently work on, but on the other hand the last thing C++ needs is yet another feature hidden under common syntax that may blow up allocations and runtime unexpectedly). EDIT: to clarify: for example, I consider std::optional as an example of a very "un-OO" type that's immensely useful. In general I like the idea from functional programming that complex types can be treated no different than primitives, rather than the OO way of wrapping and uplifting everything until even integers have methods.
- ivan_gammel 7y ago
  There’s only one case where properties may be useful - GUI forms mapped to domain-like model. In practically any other case it’s violation of one or more OO design principles. In Java you can live without them with a life full of joy.
- Jach 7y ago
  You kind of answered your own question: auto-generated getters/setters. Having a tolerable Java experience is so dependent on huge IDEs and other huge frameworks that people overlook language issues.
rcaught 7y ago
Kotlin's null safety alone is enough to prove you wrong here.
- maltalex 7y ago
  I find the whole discussion about null safety completely negligible. Since when are nulls the biggest problem for developers? Null pointer exceptions are by far some the simplest problems to avoid and/or solve. There are more serious arguments that can be made in favor of Kotlin.
  - rcaught 7y ago
    Where was it suggested that nulls are the biggest problem for developers? But they are a problem that happens, and in Kotlin, the compiler checks your nullable logic for you; instead of your users finding the errors at runtime.
    - ivan_gammel 7y ago
      It just a way to conceal bad coding practices, which doesn’t prevent from having the same problem in a different form, just like GC in JVM cannot protect from all memory leaks. I can hardly remember a case when NPE was reported by some user in my projects.
    - aflag 7y ago
      It was suggested that that feature is relevant enough to justify using kotlin over Java. However, I'd (and others in this very thread also have) argue that only slightly tips the scales towards Kotlin, while not solving the problem they were actually trying to solve here: reduce the barrier for contributing.
  - JBiserkov 7y ago
    https://duckduckgo.com/?q=billion+dollar+mistake https://duckduckgo.com/?q=billion+dollar+mistake
  - wellpast 7y ago
jackpeterfletch 7y ago
Correct null handling genuinely helps you write better, more correct, less bugged code. It's not just syntax sugar.
- pjmlp 7y ago
  Instal PMD and you are set.

deleted 7y ago

[deleted]

vbezhenar 7y ago

The only Kotlin feature that it's really hard to live without is properties. Otherwise sure, it's better than Java 11, but I can live without all those niceties. And (non)nullable types even get in my way! I just don't understand where there's syntax sugar for propeties in Java. There are lot of unneeded stuff added, that I don't really care about. But my classes are still full of autogenerated getters/setters. I recently tried to find some JEP and I did not find one. There was some talk around Java 7, but nothing since that. Nobody even wants to add properties support for Java?

sverhagen 7y ago
And (non)nullable types even get in my way! Interesting how that goes...: the sibling comment to yours said the exact opposite. How does this feature get in your way?
- vbezhenar 7y ago
  1. Language problem: if (this.prop != null) { this.prop.something() // does not work } this construction works for local variables, but not for properties. Yeah, theoretically it could be modified by another thread or function in the middle. In practice it does not happen and I'm forced to use terrible code like this.prop?.apply { prop -> prop.something() } (this example could be written as this.prop?.something() but that's not the point, usually it's harder than that. 2. Interoperation problem. A lot of Java code does not use @Nullable annotations, so all types are just that: platform types. So Kotlin nullability adds nothing to that.
  - aflag 7y ago
    What is uglier about the kotlin code? It's the same number of lines and the code is more robust. What's the ugly part?
    - vbezhenar 7y ago
      Using library functions instead of language keywords feels very wrong to me.
      - aflag 7y ago
        Why?
oweiler 7y ago
Probably because in general they are a code smell. They are anti-OO.
- vbezhenar 7y ago
  That's just not true. If I'm writing simplest REST service, I have to return JSON responses. To return JSON response, I have to write class corresponding to that response. And that will be data class. If I'm interacting with database, I'm writing data mapping classes. And that will be data class. Those are normal code that every developer writes every day. If you think that it's anti-OO, then I don't care about that OO. I care about writing performant, concise and extensible software.
  - ivan_gammel 7y ago
    That statement is valid in both contexts you mention. You do not need properties for data mapping and serialization - it’s possible to write a good OO code without getters and setters.
- antisemiotic 7y ago
  If a useful feature is incompatible with OO, it's a problem with OO, not with the feature. Properties allow one to work with plain old data (not everything is meaningfully an object with behavior) without freezing the underlying implementation forever. Fewer (or maybe more decentralized) religious arguments like this is one of the few things I like about my job in C++. (Shame C++ doesn't have properties, these would come in handy in refactoring config handling code that I currently work on, but on the other hand the last thing C++ needs is yet another feature hidden under common syntax that may blow up allocations and runtime unexpectedly). EDIT: to clarify: for example, I consider std::optional as an example of a very "un-OO" type that's immensely useful. In general I like the idea from functional programming that complex types can be treated no different than primitives, rather than the OO way of wrapping and uplifting everything until even integers have methods.
ivan_gammel 7y ago
There’s only one case where properties may be useful - GUI forms mapped to domain-like model. In practically any other case it’s violation of one or more OO design principles. In Java you can live without them with a life full of joy.
Jach 7y ago
You kind of answered your own question: auto-generated getters/setters. Having a tolerable Java experience is so dependent on huge IDEs and other huge frameworks that people overlook language issues.

rcaught 7y ago

Kotlin's null safety alone is enough to prove you wrong here.

maltalex 7y ago
I find the whole discussion about null safety completely negligible. Since when are nulls the biggest problem for developers? Null pointer exceptions are by far some the simplest problems to avoid and/or solve. There are more serious arguments that can be made in favor of Kotlin.
- rcaught 7y ago
  Where was it suggested that nulls are the biggest problem for developers? But they are a problem that happens, and in Kotlin, the compiler checks your nullable logic for you; instead of your users finding the errors at runtime.
  - ivan_gammel 7y ago
    It just a way to conceal bad coding practices, which doesn’t prevent from having the same problem in a different form, just like GC in JVM cannot protect from all memory leaks. I can hardly remember a case when NPE was reported by some user in my projects.
  - aflag 7y ago
    It was suggested that that feature is relevant enough to justify using kotlin over Java. However, I'd (and others in this very thread also have) argue that only slightly tips the scales towards Kotlin, while not solving the problem they were actually trying to solve here: reduce the barrier for contributing.
- JBiserkov 7y ago
  https://duckduckgo.com/?q=billion+dollar+mistake https://duckduckgo.com/?q=billion+dollar+mistake
- wellpast 7y ago

jackpeterfletch 7y ago

Correct null handling genuinely helps you write better, more correct, less bugged code. It's not just syntax sugar.

pjmlp 7y ago
Instal PMD and you are set.