6 ms·

Kotlin lacks the ability to do true functional programming that Swift has. Swift has pattern matching, recursive data structures (edit: specifically ADTs with

Kotlin lacks the ability to do true functional programming that Swift has. Swift has pattern matching, recursive data structures (edit: specifically ADTs with enums or case classes is what I was thinking of here, should have written algebraic data types), tail call optimization, even some form of type classes, immutability (thanks @tmail21), and so on. Kotlin does not have any of these (edit: this is now partly false, see below) I'm sad that Google is supporting Kotlin and not Swift or Scala for Android, since at least with the latter two, you can use functional programming. Edit: Actually, I'm looking into Kotlin again, and it looks like it's greatly expanded support for functional programming compared to a year or two ago. For example, algebraic data types can now be encoded in a similar manner to Scala, and kind of pseudo-pattern matched using `when`. TCO is now supported. There are lambdas, and support for closures. Destructuring assignment. But as far as I can see, still no immutable values (just immutable references), and no way to make extensible type classes, like in Scala and Swift. I'm definitely going to take another look now. Last I checked a few years ago, Kotlin had very limited support for functional programming.

pillowkusis 9y ago
Maybe you haven't checked out Kotlin lately? Kotlin has somewhat pattern matching: https://kotlinlang.org/docs/reference/control-flow.html#when-expression https://kotlinlang.org/docs/reference/control-flow.html#when... Tail call optimization: https://kotlinlang.org/docs/reference/functions.html#tail-recursive-functions https://kotlinlang.org/docs/reference/functions.html#tail-re... Type classes: https://kotlinlang.org/docs/reference/sealed-classes.html https://kotlinlang.org/docs/reference/sealed-classes.html And I'm not sure what you mean by recursive data structures. Basically every C style language I'm aware of can contain a reference to another instance of its own type. It's more java-y than Scala, but it's fundementally capable of a very FP style.
- Filligree 9y ago
  > Type classes: https://kotlinlang.org/docs/reference/sealed-classes.html https://kotlinlang.org/docs/reference/sealed-classes.html Those are not type-classes, at least not in the Haskell sense. They allow you to avoid an else branch, yes, which is actually quite useful; but one basic ability they're missing is the ability to define a new branch for a new instance of the type defined by library users. Just as an example. They're really not much like type-classes at all.
- jnbiche 9y ago
  I agree with Filligree that sealed classes are not really capable of emulating type classes. They can be used for algebraic data types, which is great, but for true extensible type classes you'd need something like Scala traits.
- masklinn 9y ago
  > Type classes: https://kotlinlang.org/docs/reference/sealed-classes.html https://kotlinlang.org/docs/reference/sealed-classes.html Sealed classes are an odd/wonky take on sum types, they're not even remotely close to type classes.
- zejay 9y ago
  Tail recursion is a special case of tail calls that can be turned into loops. Their keyword is called tailrec, so it's probably not real TCO. Real tail call optimization can't easily be turned into loops in the general case.
deleted 9y ago
[deleted]
jorgemf 9y ago
pattern matching: swift has switf and kotlin has when, both are very similar recursive data structures: I don't get this one, kotlin has all the java api available and all the third party libraries. As java has been here for much longer than swift I guess that swift is lacking more here than kotlin. Tail call optimization: kotlin has the special word tailrec for this Yes, kotlin has a lot of things. It also has co-routines like in go, it also compiles to java script and much more. The reason Google is supporting kotlin and not swift or scaala is because they have to do nothing to support it. Kotlin compiles to bytecode, so it doesnt matter your code is written in java or kotlin because when you compile it it is bytecode at the end. Scala needs to add a runtime when compiling to bytecode, it takes much longer to compile than kotlin and it is not fully compatible with java as kotlin. And Swift it is just something completely different, they should change the virtual machine in order to support it.
- jnbiche 9y ago
  Pattern matching: Kotlin has a `when` that desugars into if when statements, but it's pretty far from pattern matching like you see in Scala, Swift, and more traditional functional languages. Recursive data structures: Yeah, for some reason I wrote recursive data structure when I was thinking of algebraic data types, like Scala can encode with case classes. I often use them in Scala or OCaml to make recursive data structures which is why I mistakenly used that term instead of ADTs. TCO: glad to see I was wrong. Kotlin added support for this in the past year. Android: I realize that to support Swift on Android, Google would need to do significant work, but they wouldn't have to change the VM since Swift could also be compiled to Dalvik bytecode. But obviously that would be a lot of work. I only mention Swift since there were rumors in the past that Google was considering fully supporting Swift on Android. Plus, to be clear, you can run Swift on Android now using the native SDK, just not on Dalvik for making GUI apps.
  - jorgemf 9y ago
    > Kotlin has a `when` that desugars into if when statements Actually not. Not now, probably it was the case at the begining of the language. > algebraic data types they removed some restriction of sealed classes in 1.1. So I am not sure this is true anymore. The memory management in Swift is completely different than in Java. That is the main reason you need to make changes in the virtual machine. JVM uses the garbage collector while swift uses reference counter.
tmail21 9y ago
What about immutability? A key part of functional programming is using immutable structures to avoid side effects. My understanding is that Swift has these to some extent ("let" vs "var", structs being immutable etc). And since Kotlin is built on JVM compatibility I _assume_ that Kotlin does not support an immutable style of programming. Maybe someone here has more clarity on this.
- jnbiche 9y ago
  Yes, and immutability! Kotlin has not much support for this, unless it's also been added in the past year. Both Clojure and Scala that run on JVM have strong support for immutability, so it's quite possible on the JVM. And yes, Swift has let binding, and other features to support immutability.
- jorgemf 9y ago
  You can have immutability by making the setters methods of a class private. So if you combine it with "val" you have immutable objects. It is a bit more job in kotlin but as it is also object oriented programming you can achieve exactly what you want. And for structures you have list, mutablelist, map, mutablemap, etc. What else do you want?
  - tmail21 9y ago
    Looks like there is some distinction between Mutable, Read-only View and Immutable. According to this http://stackoverflow.com/questions/33727657/kotlin-and-immutable-collections http://stackoverflow.com/questions/33727657/kotlin-and-immut... Kotlin does not support true immutability. For immutability to be practical one would need to implement structural sharing in their collections otherwise copying would be prohibitively expensive. This Java library seems to be trying to implement this. http://www.vavr.io/ http://www.vavr.io/ Again, I am not saying that Kotlin does not support immutability, just trying to get to the bottom of the reality of it.
    - jorgemf 9y ago
      I get your point now. Yes, it is read-only, not immutable. For me, I only need read-only. I think kotlin wasn't meant to be pure functional. I see it as object oriented with some functional programming. out of curiosity, what cases will you use an immutable collection instead of a read-only? I cannot imagine any use case where immutable is a gain over read-only.
s73ver 9y ago
Well, Google has to do extremely little to support Kotlin, as it runs on the JVM, does so fairly leanly, and does so on Java 6 JVMs. Swift, they'd have to redo just about their entire stack, as Swift doesn't run on the JVM (Swift can be used with the NDK to build NDK libraries, but it's not standard to build a full app, outside of games, with that). Scala has had big issues with the size of it's library that still haven't been resolved, and the new versions of Scala require Java 8, which only the beta version of Android supports right now.
nickbauman 9y ago
> Kotlin lacks the ability to do true functional programming... Same goes for Swift. Any "hybrid oo functional" language will not do the functional thing as well as a dedicated functional language. If you're still gluing things together with types, functions will never be quite as first-class as they should be.

pillowkusis 9y ago

Maybe you haven't checked out Kotlin lately? Kotlin has somewhat pattern matching: https://kotlinlang.org/docs/reference/control-flow.html#when-expression https://kotlinlang.org/docs/reference/control-flow.html#when... Tail call optimization: https://kotlinlang.org/docs/reference/functions.html#tail-recursive-functions https://kotlinlang.org/docs/reference/functions.html#tail-re... Type classes: https://kotlinlang.org/docs/reference/sealed-classes.html https://kotlinlang.org/docs/reference/sealed-classes.html And I'm not sure what you mean by recursive data structures. Basically every C style language I'm aware of can contain a reference to another instance of its own type. It's more java-y than Scala, but it's fundementally capable of a very FP style.

Filligree 9y ago
> Type classes: https://kotlinlang.org/docs/reference/sealed-classes.html https://kotlinlang.org/docs/reference/sealed-classes.html Those are not type-classes, at least not in the Haskell sense. They allow you to avoid an else branch, yes, which is actually quite useful; but one basic ability they're missing is the ability to define a new branch for a new instance of the type defined by library users. Just as an example. They're really not much like type-classes at all.
jnbiche 9y ago
I agree with Filligree that sealed classes are not really capable of emulating type classes. They can be used for algebraic data types, which is great, but for true extensible type classes you'd need something like Scala traits.
masklinn 9y ago
> Type classes: https://kotlinlang.org/docs/reference/sealed-classes.html https://kotlinlang.org/docs/reference/sealed-classes.html Sealed classes are an odd/wonky take on sum types, they're not even remotely close to type classes.
zejay 9y ago
Tail recursion is a special case of tail calls that can be turned into loops. Their keyword is called tailrec, so it's probably not real TCO. Real tail call optimization can't easily be turned into loops in the general case.

deleted 9y ago

[deleted]

jorgemf 9y ago

pattern matching: swift has switf and kotlin has when, both are very similar recursive data structures: I don't get this one, kotlin has all the java api available and all the third party libraries. As java has been here for much longer than swift I guess that swift is lacking more here than kotlin. Tail call optimization: kotlin has the special word tailrec for this Yes, kotlin has a lot of things. It also has co-routines like in go, it also compiles to java script and much more. The reason Google is supporting kotlin and not swift or scaala is because they have to do nothing to support it. Kotlin compiles to bytecode, so it doesnt matter your code is written in java or kotlin because when you compile it it is bytecode at the end. Scala needs to add a runtime when compiling to bytecode, it takes much longer to compile than kotlin and it is not fully compatible with java as kotlin. And Swift it is just something completely different, they should change the virtual machine in order to support it.

jnbiche 9y ago
Pattern matching: Kotlin has a `when` that desugars into if when statements, but it's pretty far from pattern matching like you see in Scala, Swift, and more traditional functional languages. Recursive data structures: Yeah, for some reason I wrote recursive data structure when I was thinking of algebraic data types, like Scala can encode with case classes. I often use them in Scala or OCaml to make recursive data structures which is why I mistakenly used that term instead of ADTs. TCO: glad to see I was wrong. Kotlin added support for this in the past year. Android: I realize that to support Swift on Android, Google would need to do significant work, but they wouldn't have to change the VM since Swift could also be compiled to Dalvik bytecode. But obviously that would be a lot of work. I only mention Swift since there were rumors in the past that Google was considering fully supporting Swift on Android. Plus, to be clear, you can run Swift on Android now using the native SDK, just not on Dalvik for making GUI apps.
- jorgemf 9y ago
  > Kotlin has a `when` that desugars into if when statements Actually not. Not now, probably it was the case at the begining of the language. > algebraic data types they removed some restriction of sealed classes in 1.1. So I am not sure this is true anymore. The memory management in Swift is completely different than in Java. That is the main reason you need to make changes in the virtual machine. JVM uses the garbage collector while swift uses reference counter.

tmail21 9y ago

What about immutability? A key part of functional programming is using immutable structures to avoid side effects. My understanding is that Swift has these to some extent ("let" vs "var", structs being immutable etc). And since Kotlin is built on JVM compatibility I _assume_ that Kotlin does not support an immutable style of programming. Maybe someone here has more clarity on this.

jnbiche 9y ago
Yes, and immutability! Kotlin has not much support for this, unless it's also been added in the past year. Both Clojure and Scala that run on JVM have strong support for immutability, so it's quite possible on the JVM. And yes, Swift has let binding, and other features to support immutability.
jorgemf 9y ago
You can have immutability by making the setters methods of a class private. So if you combine it with "val" you have immutable objects. It is a bit more job in kotlin but as it is also object oriented programming you can achieve exactly what you want. And for structures you have list, mutablelist, map, mutablemap, etc. What else do you want?
- tmail21 9y ago
  Looks like there is some distinction between Mutable, Read-only View and Immutable. According to this http://stackoverflow.com/questions/33727657/kotlin-and-immutable-collections http://stackoverflow.com/questions/33727657/kotlin-and-immut... Kotlin does not support true immutability. For immutability to be practical one would need to implement structural sharing in their collections otherwise copying would be prohibitively expensive. This Java library seems to be trying to implement this. http://www.vavr.io/ http://www.vavr.io/ Again, I am not saying that Kotlin does not support immutability, just trying to get to the bottom of the reality of it.
  - jorgemf 9y ago
    I get your point now. Yes, it is read-only, not immutable. For me, I only need read-only. I think kotlin wasn't meant to be pure functional. I see it as object oriented with some functional programming. out of curiosity, what cases will you use an immutable collection instead of a read-only? I cannot imagine any use case where immutable is a gain over read-only.

s73ver 9y ago

Well, Google has to do extremely little to support Kotlin, as it runs on the JVM, does so fairly leanly, and does so on Java 6 JVMs. Swift, they'd have to redo just about their entire stack, as Swift doesn't run on the JVM (Swift can be used with the NDK to build NDK libraries, but it's not standard to build a full app, outside of games, with that). Scala has had big issues with the size of it's library that still haven't been resolved, and the new versions of Scala require Java 8, which only the beta version of Android supports right now.

nickbauman 9y ago

> Kotlin lacks the ability to do true functional programming... Same goes for Swift. Any "hybrid oo functional" language will not do the functional thing as well as a dedicated functional language. If you're still gluing things together with types, functions will never be quite as first-class as they should be.