3 ms·

> To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features. That sounds very good. Scala overdid it.

by lann 11y ago

biggestbob 11y ago
You are wrong.
justthistime_ 11y ago
Not sure I get your point. I would both prefer a language which either had 20% of the futures and 20% of the cost, or 100% of the futures and 100% of the cost. In Kotlin you get stuff like extension methods, which bear almost all the costs of implicit values, but don't support most use-cases you would use implicit classes for.
- mike_hearn 11y ago
  Extension methods vs implicits is one of those things that people seem to really like about Kotlin, on the balance of comments I've read. For instance because they are more predictable, higher performance, implicits are apparently a leading source of Scala compiler slowness, because to fix the issues with implicits you end up needing what Scala calls value types (but which have so many restrictions, they're more like type aliases than actual value types), etc.
  - justthistime_ 11y ago
    I think you got all of that pretty mixed up. - Implicit resolution can be slow, because you can make the compiler do arbitrary work for you. This is completely unrelated to implicit classes themselves. - Scala had the option to either not ship value types at all, or support only a limited subset of things that can be made work well under the current restrictions. If Scala didn't ship value types, the JVM would have probably never gotten them. You can thank Scala developers later for dragging Java people into the 1990ies. - Extension methods looks totally cool on paper, but are pretty much useless for writing maintainable, readable code, which also does something useful: Dev: "Ok, I want to be able to use String as if it was a collection of chars." Kotlin: "Sure, just implement all the collection methods one-by-one." Dev: "But, but ... all implementations I need are already implemented in that trait over there?" Kotlin: "Bad luck, I guess. You could of course just delegate all your methods to that trait." Dev: "But then I would need to create a real instance of that trait first which implements the missing abstract method ... that's more boilerplate than just copy-and-pasting the code?" Kotlin: "Yeah, you have to decide whether to write a short implementation on your own or pay the price for sharing common pieces of code." Dev: "... <much later> ... ok, I now implemented all all the methods of the collection interface of my own ... I guess ... the compiler will warn me if I forgot to implement a method from that interface or messed up a signature, right?" Kotlin: "No." Dev: "I just tried passing my String to a method expecting a collection ... it doesn't even compile?" Kotlin: "Just because you went to all the trouble to make String act like a collection doesn't mean it's supported as soon as abstraction enters the picture." Dev: "So I can write cute things like myString.map(...) but as soon as map(...) is moved to a method, I have to overload that method to accept both Strings and collections?" Kotlin: "You could also just write a StringCollectionWrapper and wrap every String in that when you need it." Dev: "I guess the compiler will figure out when I need to wrap it?" Kotlin: "No, you have wrap it manually every single time." Dev: "So extension methods are basically just syntax for writing static methods in a nicer way?" Kotlin: "Can you please stop asking questions while I waste your time?"
    - mike_hearn 11y ago
      "foo".asSequence() works fine. I understood your long hypothetical conversation: you want to avoid an intermediary method that returns a collection of chars. I just fail to see why anyone would care about this.
      - justthistime_ 11y ago
        No, I don't think you understood it. There is a large qualitative gap between what you propose, and what Scala does: In Scala, it is an _one_ time effort to make String act "like" collections, while the only solution Kotlin provides means doing the work manually _n_ times: At every call site of the string in question. Kotlin developers also didn't feel like your point was too convincing: https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/generated/_Strings.kt https://github.com/JetBrains/kotlin/blob/master/libraries/st...
        mike_hearn 11y ago
        That file contains the definitions of asList and asSequence, for example. If you're saying "but look at the other methods", that's not very convincing to me either because honestly I don't think having a fold method directly on String is very useful - if they scrapped a lot of those extension methods I'd be totally OK with that. At any rate, you never addressed the core point I raised. Saying "implicit resolution isn't related to implicit classes" doesn't seem very convincing. If solving that issue was so easy then why is the use of implicits so frequently identified as a performance issue for tools?
    - incepted 11y ago
      > But then I would need to create a real instance of that trait first which implements the missing abstract metho You don't seem to know that Kotlin supports delegation natively. Look up the `by` keyword. And please just post some code next time you're trying to make a point like this because this dialogue is pretty much impossible to follow.

> To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features. That sounds very good. Scala overdid it.

by lann 11y ago

> To me it feels Kotlin paid 80% of the cost of features, but got only 20% worth of features. That sounds very good. Scala overdid it.

biggestbob 11y ago

You are wrong.

justthistime_ 11y ago

Not sure I get your point. I would both prefer a language which either had 20% of the futures and 20% of the cost, or 100% of the futures and 100% of the cost. In Kotlin you get stuff like extension methods, which bear almost all the costs of implicit values, but don't support most use-cases you would use implicit classes for.

mike_hearn 11y ago
Extension methods vs implicits is one of those things that people seem to really like about Kotlin, on the balance of comments I've read. For instance because they are more predictable, higher performance, implicits are apparently a leading source of Scala compiler slowness, because to fix the issues with implicits you end up needing what Scala calls value types (but which have so many restrictions, they're more like type aliases than actual value types), etc.
- justthistime_ 11y ago
  I think you got all of that pretty mixed up. - Implicit resolution can be slow, because you can make the compiler do arbitrary work for you. This is completely unrelated to implicit classes themselves. - Scala had the option to either not ship value types at all, or support only a limited subset of things that can be made work well under the current restrictions. If Scala didn't ship value types, the JVM would have probably never gotten them. You can thank Scala developers later for dragging Java people into the 1990ies. - Extension methods looks totally cool on paper, but are pretty much useless for writing maintainable, readable code, which also does something useful: Dev: "Ok, I want to be able to use String as if it was a collection of chars." Kotlin: "Sure, just implement all the collection methods one-by-one." Dev: "But, but ... all implementations I need are already implemented in that trait over there?" Kotlin: "Bad luck, I guess. You could of course just delegate all your methods to that trait." Dev: "But then I would need to create a real instance of that trait first which implements the missing abstract method ... that's more boilerplate than just copy-and-pasting the code?" Kotlin: "Yeah, you have to decide whether to write a short implementation on your own or pay the price for sharing common pieces of code." Dev: "... <much later> ... ok, I now implemented all all the methods of the collection interface of my own ... I guess ... the compiler will warn me if I forgot to implement a method from that interface or messed up a signature, right?" Kotlin: "No." Dev: "I just tried passing my String to a method expecting a collection ... it doesn't even compile?" Kotlin: "Just because you went to all the trouble to make String act like a collection doesn't mean it's supported as soon as abstraction enters the picture." Dev: "So I can write cute things like myString.map(...) but as soon as map(...) is moved to a method, I have to overload that method to accept both Strings and collections?" Kotlin: "You could also just write a StringCollectionWrapper and wrap every String in that when you need it." Dev: "I guess the compiler will figure out when I need to wrap it?" Kotlin: "No, you have wrap it manually every single time." Dev: "So extension methods are basically just syntax for writing static methods in a nicer way?" Kotlin: "Can you please stop asking questions while I waste your time?"
  - mike_hearn 11y ago
    "foo".asSequence() works fine. I understood your long hypothetical conversation: you want to avoid an intermediary method that returns a collection of chars. I just fail to see why anyone would care about this.
    - justthistime_ 11y ago
      No, I don't think you understood it. There is a large qualitative gap between what you propose, and what Scala does: In Scala, it is an _one_ time effort to make String act "like" collections, while the only solution Kotlin provides means doing the work manually _n_ times: At every call site of the string in question. Kotlin developers also didn't feel like your point was too convincing: https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/generated/_Strings.kt https://github.com/JetBrains/kotlin/blob/master/libraries/st...
      - mike_hearn 11y ago
        That file contains the definitions of asList and asSequence, for example. If you're saying "but look at the other methods", that's not very convincing to me either because honestly I don't think having a fold method directly on String is very useful - if they scrapped a lot of those extension methods I'd be totally OK with that. At any rate, you never addressed the core point I raised. Saying "implicit resolution isn't related to implicit classes" doesn't seem very convincing. If solving that issue was so easy then why is the use of implicits so frequently identified as a performance issue for tools?
  - incepted 11y ago
    > But then I would need to create a real instance of that trait first which implements the missing abstract metho You don't seem to know that Kotlin supports delegation natively. Look up the `by` keyword. And please just post some code next time you're trying to make a point like this because this dialogue is pretty much impossible to follow.