4 ms·

what type of language is kotlin? Is it functional , OOP or something else, which paradigm does it represent?

by systems 2y ago

deleted 2y ago
[deleted]
eriksencosta 2y ago
Kotlin is a multi-paradigm language with OOP and FP support.
lolinder 2y ago
It's all of the above. Most modern languages (including everything from Java to OCaml) don't fit neatly in any one box because they have added a bunch of features from other paradigms that make multi-paradigm programming possible. Kotlin is that way to an extreme, because instead of strapping on functional features to an OOP core like Java did it was designed out of the gate to be all of the above. When I program in Kotlin I'm constantly shifting between "paradigms" based on what is actually needed in the moment. It's one of the best languages I've ever worked with for learning the strengths and weaknesses of different programming styles because it has such strong support for most of them.
moritzruth 2y ago
Kotlin was originally designed for running on the JVM, so it is generally object-oriented, but the language and the standard library allow for and encourage a functional coding style. Kotlin is well-suited for DSLs, especially declarative ones (see kotlinx.html[0]). [0] https://github.com/Kotlin/kotlinx.html https://github.com/Kotlin/kotlinx.html
- graypegg 2y ago
  Huh, I've never actually looked too hard at Kotlin. That is a lot more syntactically flexible than I thought it was! That HTML builder reminds me of Ruby DSLs a lot.
  - dtech 2y ago
    It's not really syntactically flexible, but made explicit syntax for the use cases other languages used flexibility for, like DSL-builders and extension methods. This avoid the problem that you have in more flexible languages where everyone does a pattern in a slightly different way.
- lolinder 2y ago
  This understates how functional Kotlin is—you wouldn't say that Scala is generally OOP with some functional support just because it was built on the JVM. Scala's clearly a functional language with some OOP support. Kotlin, in turn, is very balanced. The standard collection library uses OOP syntax (chains of method calls), but is extremely functional in its philosophy towards how we think about manipulating collections.
  - ragnese 2y ago
    I think a comparison to Scala is apt. Working with both languages makes it quite clear to me that Scala is most certainly much more functional than Kotlin. Kotlin is really not very functional in practice, in that it really doesn't encourage a functional style, nor is it optimized for the patterns that are common in functional programming. Scala has `Try` and `Either` for modeling domain failures as values as opposed to throwing (unchecked) exceptions, which are side-effecting. Scala also has for-comprehension syntax built in to make it more convenient to compose and chain fallible operations that use `Try`, `Either, `Option`, etc. Kotlin's `Result` type is not designed for modeling fallible operations (not a sealed class, no type parameter on the error variant, error must be `Throwable`, etc), and Kotlin does not offer convenient syntax like for-comprehensions despite being more than able to (given that many of us have implemented near-perfect analogues to Scala's `Try` and for-comprehension syntax in Kotlin). Similarly, no official Kotlin libraries or APIs ever return errors as values and always opt for throwing exceptions instead. Scala's collection types are implemented as persistent collections, which are optimized for cheap updates. If you want to avoid direct mutation in Kotlin, you have to make a full copy of a collection. Scala's mutable and immutable collection types are actually distinct from each other and cannot be used interchangeably. In Kotlin, List<T> is a supertype of MutableList<T>, which means I can pass a MutableList into a function that expects a List. That means that the list can be changed in another thread while my function is running, so I can't even assume that checking `list.size` at two different points in my function will return the same value. Scala has actual type classes. Kotlin has extension functions which are not nearly as useful (and they have very surprising semantics when it comes to static vs dynamic dispatch). Type classes are certainly not required for functional programming with a statically typed language, but it definitely helps when it comes to modeling things without needing to lean on writing more classes and/or utilizing inheritance. Also, Kotlin's "functional" APIs on collections are much more janky than Scala's. For example, if I have a `Set<T>` and I call `.map((T) -> R)` on it, Kotlin will give me a `List<R>` while Scala will give me a `Set<R>`, which makes way more sense. Kotlin is cool, and it would be dishonest for me to say that it's not at all functional, but after having worked in other many other languages, I'm very comfortable saying that Kotlin is an OOP/imperative language first with some functional stuff added in (sealed classes, convenient lambda syntax, top-level functions, and some of the typical collection combinator APIs). Whereas Scala is quite clearly designed to be actually GOOD for functional programming without taking an extra-hard performance hit.
- School-Cotton 2y ago
  The JVM doesn't necessarily imply object-orientation. Clojure (a JVM language) is not really object-oriented at all; I'm not an expert but I think the only time objects are used in idiomatic Clojure is when doing interop with Java libraries.
deleted 2y ago
[deleted]
ragnese 2y ago
It's much more "multi-paradigm" or "unopinionated" than Java, but since it is a pretty thin layer over Java and uses its standard library, the ecosystem and idioms are still very much OOP by convention. But, I see the language itself as more akin to C++ in that it really doesn't strongly push much in one direction or another, but they also both lack built-in tools or optimizations for doing real functional programming. So, I'd say that Kotlin, like C++, is an unopinionated language that does well for OOP and/or imperative styles.
beeforpork 2y ago
Like Java, but nicer. Used for Android app devel. Me, I would not call it multi-paradigm, because it really feels primarily like Java (though with many niceties), i.e., it is single dispatch ('this'), objects and classes everywhere. It is completely compatible with Java, and you can mix the languages freely (this is done in Android). It does have standalone functions.
g-b-r 2y ago
A mess, in my limited experience, so far
speed_spread 2y ago
As a Java replacement, it's still mainly an OOP paradigm with some functional bits added. The type system is mostly unchanged from Java. Kotlin's null safety is interesting, but JVM null pointers are nowhere near the problem they are in C. Otherwise its value proposition mostly relies on overcoming perceived constraints from Java syntax, allowing to redefine parts of the language to build DSLs. Whether this is a good idea is disputable; ask any maintainer of large projects where those capabilities were used in full, or just look at the continuing train wreck that is Gradle.

what type of language is kotlin? Is it functional , OOP or something else, which paradigm does it represent?

deleted 2y ago

[deleted]

eriksencosta 2y ago

Kotlin is a multi-paradigm language with OOP and FP support.

lolinder 2y ago

It's all of the above. Most modern languages (including everything from Java to OCaml) don't fit neatly in any one box because they have added a bunch of features from other paradigms that make multi-paradigm programming possible. Kotlin is that way to an extreme, because instead of strapping on functional features to an OOP core like Java did it was designed out of the gate to be all of the above. When I program in Kotlin I'm constantly shifting between "paradigms" based on what is actually needed in the moment. It's one of the best languages I've ever worked with for learning the strengths and weaknesses of different programming styles because it has such strong support for most of them.

moritzruth 2y ago

Kotlin was originally designed for running on the JVM, so it is generally object-oriented, but the language and the standard library allow for and encourage a functional coding style. Kotlin is well-suited for DSLs, especially declarative ones (see kotlinx.html[0]). [0] https://github.com/Kotlin/kotlinx.html https://github.com/Kotlin/kotlinx.html

graypegg 2y ago
Huh, I've never actually looked too hard at Kotlin. That is a lot more syntactically flexible than I thought it was! That HTML builder reminds me of Ruby DSLs a lot.
- dtech 2y ago
  It's not really syntactically flexible, but made explicit syntax for the use cases other languages used flexibility for, like DSL-builders and extension methods. This avoid the problem that you have in more flexible languages where everyone does a pattern in a slightly different way.
lolinder 2y ago
This understates how functional Kotlin is—you wouldn't say that Scala is generally OOP with some functional support just because it was built on the JVM. Scala's clearly a functional language with some OOP support. Kotlin, in turn, is very balanced. The standard collection library uses OOP syntax (chains of method calls), but is extremely functional in its philosophy towards how we think about manipulating collections.
- ragnese 2y ago
  I think a comparison to Scala is apt. Working with both languages makes it quite clear to me that Scala is most certainly much more functional than Kotlin. Kotlin is really not very functional in practice, in that it really doesn't encourage a functional style, nor is it optimized for the patterns that are common in functional programming. Scala has `Try` and `Either` for modeling domain failures as values as opposed to throwing (unchecked) exceptions, which are side-effecting. Scala also has for-comprehension syntax built in to make it more convenient to compose and chain fallible operations that use `Try`, `Either, `Option`, etc. Kotlin's `Result` type is not designed for modeling fallible operations (not a sealed class, no type parameter on the error variant, error must be `Throwable`, etc), and Kotlin does not offer convenient syntax like for-comprehensions despite being more than able to (given that many of us have implemented near-perfect analogues to Scala's `Try` and for-comprehension syntax in Kotlin). Similarly, no official Kotlin libraries or APIs ever return errors as values and always opt for throwing exceptions instead. Scala's collection types are implemented as persistent collections, which are optimized for cheap updates. If you want to avoid direct mutation in Kotlin, you have to make a full copy of a collection. Scala's mutable and immutable collection types are actually distinct from each other and cannot be used interchangeably. In Kotlin, List<T> is a supertype of MutableList<T>, which means I can pass a MutableList into a function that expects a List. That means that the list can be changed in another thread while my function is running, so I can't even assume that checking `list.size` at two different points in my function will return the same value. Scala has actual type classes. Kotlin has extension functions which are not nearly as useful (and they have very surprising semantics when it comes to static vs dynamic dispatch). Type classes are certainly not required for functional programming with a statically typed language, but it definitely helps when it comes to modeling things without needing to lean on writing more classes and/or utilizing inheritance. Also, Kotlin's "functional" APIs on collections are much more janky than Scala's. For example, if I have a `Set<T>` and I call `.map((T) -> R)` on it, Kotlin will give me a `List<R>` while Scala will give me a `Set<R>`, which makes way more sense. Kotlin is cool, and it would be dishonest for me to say that it's not at all functional, but after having worked in other many other languages, I'm very comfortable saying that Kotlin is an OOP/imperative language first with some functional stuff added in (sealed classes, convenient lambda syntax, top-level functions, and some of the typical collection combinator APIs). Whereas Scala is quite clearly designed to be actually GOOD for functional programming without taking an extra-hard performance hit.
School-Cotton 2y ago
The JVM doesn't necessarily imply object-orientation. Clojure (a JVM language) is not really object-oriented at all; I'm not an expert but I think the only time objects are used in idiomatic Clojure is when doing interop with Java libraries.

deleted 2y ago

[deleted]

ragnese 2y ago

It's much more "multi-paradigm" or "unopinionated" than Java, but since it is a pretty thin layer over Java and uses its standard library, the ecosystem and idioms are still very much OOP by convention. But, I see the language itself as more akin to C++ in that it really doesn't strongly push much in one direction or another, but they also both lack built-in tools or optimizations for doing real functional programming. So, I'd say that Kotlin, like C++, is an unopinionated language that does well for OOP and/or imperative styles.

beeforpork 2y ago

Like Java, but nicer. Used for Android app devel. Me, I would not call it multi-paradigm, because it really feels primarily like Java (though with many niceties), i.e., it is single dispatch ('this'), objects and classes everywhere. It is completely compatible with Java, and you can mix the languages freely (this is done in Android). It does have standalone functions.

g-b-r 2y ago

A mess, in my limited experience, so far

speed_spread 2y ago

As a Java replacement, it's still mainly an OOP paradigm with some functional bits added. The type system is mostly unchanged from Java. Kotlin's null safety is interesting, but JVM null pointers are nowhere near the problem they are in C. Otherwise its value proposition mostly relies on overcoming perceived constraints from Java syntax, allowing to redefine parts of the language to build DSLs. Whether this is a good idea is disputable; ask any maintainer of large projects where those capabilities were used in full, or just look at the continuing train wreck that is Gradle.