As for the last question: You can pretty easily accomplish that with a simple extension function: inline operator fun T.invoke(lambda: T.() -> Unit) = lambda(this)
@Jon Do Haven't seen the ideo yet, but if you try to run that code. you gonna be dispointed. That lambda doesn't even take a param. Now, you could run that code without passing this in as a param, and rather use this.lambda()
I'm not an expert, but since you haven't received any better answer... Kotlin isn't as powerful for a functional language as Scala, it's missing some constructs such as union types, for example (and some can be just emulated). And this is by design, Kotlin is meant to remain a "friendly", hybrid language. On the other hand, Scala syntax can be intimidating and it's easier to write virtually incomprehensible code in Scala Kotlin is probably best suited for "diet" functional programming where you don't intend to take the paradigm all the way. So I guess the advantage of Kotlin over Scala, or vice versa, comes down to the technical background of the team, and the project requirements (full blown FP vs. FP-flavored)
It's an interesting talk which could be better if it wasn't for some slip-ups. Let me share a few nitpicks 3:11 While I agree with the general message, to be fair, your imperative implementation is obfuscated by poor naming as much as by its imperativeness. The "element" variable is misnamed. It clearly doesn't represent an element - an element is element[i]. Your "element" represents the number of occurrences of a given element, and the name should reflect that for the code to be readable. In my case this by itself was responsible for most of the delay in figuring out what the code does. Poor naming can be more of an obstacle than poor code structure. 20:43 - inside the numbers.forEach, what is "numbers % 5 == 0" supposed to mean? You probably meant "it % 5 == 0" 25:48 - putting const on a getter of Date type makes no sense at all. const can't have a getter. And const can't be used for non-primitive types (such as Date) either; strings being a sole exception. You haven't correctly indicated how the keyword works and what it is for, only created more confusion. 37:25 - "this I can do in shorthand". But what you do then isn't a shorthand for what you had before at all. "this is the same as doing an if". But no, it's not the same. You don't have println. Just the value. And println(s?.length) - which is what someone might thought they'd need, relying on your words - would actually execute println with a null argument, if s were null. This isn't clear from your explanation. For the code to really do the same thing you'd need something like s?.length?.let(::println), or s?.run { println(length) } etc. This piece of the puzzle is missing. 42:50 to 43:07 - I doubt if anyone who doesn't already know how it works from elsewhere actually understood the (non-)explanation...
Nice presentation, but I haven't got what the last part about DSL capabilities of Kotlin have to do with functional programming. (except that functions are used for DSL)
Because google decided so, i'd say. Additionally, the java-compatibility thing is quite important too, with kotlin you can without issues continue a java app in the new language. With scala you're going to have to be quite careful. Thus, kotlin has much easier access to the java ecosystem.
@@_DATA_EXPUNGED_ Also there are just way too many ways to do things and sometimes pretty exotic and fancy things (in a bad way when it comes to software development as a team). The Scala community kind of sucks too. I do like Scala. Some people consider Kotlin as sane Scala. I think that's one way to look at it :)
Kotlin's stronghold, and arguably the driving force behind its adoption, became Android, because developers were really stuck with Java, and unlike on backend, it wasn't even new versions of Java (unavailable, due to VM limitations). Scala never made a dent there - despite some attempts, it was never adopted for Android development. the notoriously long build times probably played a role (while one of the design goals of Kotlin was to be as fast as Java in this regard). and yes, another important issue is interoperability with Java. it's quite limited with Scala, while Kotlin is fully interoperable (some unavoidable quirks notwithstanding). this was again among Kotlin's chief design goals, and it's of particular importance on Android. finally - although this is subjective - Scala falls a bit on the "academic" side of languages, while Kotlin has a simpler, friendlier feel to it.
What is the point of using Option, when Kotlin has it built in? All the examples shown in the presentation would be much shorter and more readable with Int? instead of Option.
Kotlin's nullable types are nulls (for the sake of interoperability with Java). If you use a library that doesn't allow for nullability, like - most prominently - RxJava 2, then you can't send an instance of T? down the stream. It'll crash on a null in runtime. If you can't control the source of data, and/or refactoring the entire thing to remove nullability isn't easy, then you could use Optional as a value wrapper for "absent" values. Note the same problem doesn't exist in the - otherwise very similar - Swift, where the issue of Java interoperability obviously doesn't apply, and conversely, T? types in Swift are syntax sugar for Optionals.
he added a live template which replaces the florin symbol (OPT+F on us-keyboard macs) with the lowercase lambda, but you can also use any other identifier, like "lambda"
We can call it "functional programming", but that kind of misses the point of using words. You can do this stuff in almost any language used today. I would argue, that the real difference is between pure functional languages like haskell, nix or elm, and all the other languages. Pure func. languages have referential transparency, that allow the compiler to make guarantees about the code, can give you hints, can make optimizations, and can execute it in the order it wants. To get this to work you can not have variable mutation and you need to carefully seperate side-effectful code from pure code. This distinction is not made in all the popular languages. And to complicate things further, there are even languages like scala, that allow you to optionally seperate these things, so it's the responsibility of the programmer to make it work, but the compiler doesn't really care. Mixing those things in Haskell would result in a compile time error. Maybe Hello Bessoni Rodrigues is right and we should just view "functional programming" as a style (independently from the language) where you just put maps and filters where you had for-loops previously, but that would be very different to what you get with pure functional programming, so using the term like this is kind of misleading, and the terms "functional programming" and "pure functional programming" would fall into to different categories.
I agree. This is a bit like saying "I touched an object, therefore I do OOP". Imagine if this object is just a backet for some main() function, and within this function you're referring to Console or something, but it's all spaghetti, then yes you're technically dealing with some objects, but you're writing procedural code regardless :)
As for the last question: You can pretty easily accomplish that with a simple extension function:
inline operator fun T.invoke(lambda: T.() -> Unit) = lambda(this)
@Jon Do Haven't seen the ideo yet, but if you try to run that code. you gonna be dispointed. That lambda doesn't even take a param. Now, you could run that code without passing this in as a param, and rather use this.lambda()
It was interesting especially the final part about sample DSL in Kotlin using extension function passing into higher-order function
how life would be easier with functional paradigm . special thanks to Hadi Hariri
Can’t you have functions as objects in OOP?
Nice presentation. Basically everything what is new and about Kotlin is nice :)
Simple and understandable. Thanks alot
Great talk! Didn't know this Arrow KT library. Thank you!
That DSL won't work unless you call f() from your invoke operator function. It should be: operator fun invoke(f: Configuration.() -> Unit) = f()
As well one improvement idea. People like seeing code running :)
Is there an advantage to use Kotlin over Scala for functional programming though?
This is a serious and honest question
I'm not an expert, but since you haven't received any better answer...
Kotlin isn't as powerful for a functional language as Scala, it's missing some constructs such as union types, for example (and some can be just emulated).
And this is by design, Kotlin is meant to remain a "friendly", hybrid language.
On the other hand, Scala syntax can be intimidating and it's easier to write virtually incomprehensible code in Scala
Kotlin is probably best suited for "diet" functional programming where you don't intend to take the paradigm all the way.
So I guess the advantage of Kotlin over Scala, or vice versa, comes down to the technical background of the team, and the project requirements (full blown FP vs. FP-flavored)
It's an interesting talk which could be better if it wasn't for some slip-ups. Let me share a few nitpicks
3:11 While I agree with the general message, to be fair, your imperative implementation is obfuscated by poor naming as much as by its imperativeness. The "element" variable is misnamed. It clearly doesn't represent an element - an element is element[i]. Your "element" represents the number of occurrences of a given element, and the name should reflect that for the code to be readable. In my case this by itself was responsible for most of the delay in figuring out what the code does. Poor naming can be more of an obstacle than poor code structure.
20:43 - inside the numbers.forEach, what is "numbers % 5 == 0" supposed to mean? You probably meant "it % 5 == 0"
25:48 - putting const on a getter of Date type makes no sense at all. const can't have a getter. And const can't be used for non-primitive types (such as Date) either; strings being a sole exception. You haven't correctly indicated how the keyword works and what it is for, only created more confusion.
37:25 - "this I can do in shorthand". But what you do then isn't a shorthand for what you had before at all. "this is the same as doing an if". But no, it's not the same. You don't have println. Just the value. And println(s?.length) - which is what someone might thought they'd need, relying on your words - would actually execute println with a null argument, if s were null. This isn't clear from your explanation. For the code to really do the same thing you'd need something like s?.length?.let(::println), or s?.run { println(length) } etc. This piece of the puzzle is missing.
42:50 to 43:07 - I doubt if anyone who doesn't already know how it works from elsewhere actually understood the (non-)explanation...
Nice presentation, but I haven't got what the last part about DSL capabilities of Kotlin have to do with functional programming. (except that functions are used for DSL)
how about curring
Currying*. Arrow supports it.
Thanks?, Hadi.
Honest question. Why was Kotlin invented, when they already had Scala. Also why did Scala start losing out to Kotlin?
Because google decided so, i'd say.
Additionally, the java-compatibility thing is quite important too, with kotlin you can without issues continue a java app in the new language. With scala you're going to have to be quite careful.
Thus, kotlin has much easier access to the java ecosystem.
@@_DATA_EXPUNGED_ Also there are just way too many ways to do things and sometimes pretty exotic and fancy things (in a bad way when it comes to software development as a team). The Scala community kind of sucks too.
I do like Scala. Some people consider Kotlin as sane Scala. I think that's one way to look at it :)
Kotlin's stronghold, and arguably the driving force behind its adoption, became Android, because developers were really stuck with Java, and unlike on backend, it wasn't even new versions of Java (unavailable, due to VM limitations).
Scala never made a dent there - despite some attempts, it was never adopted for Android development.
the notoriously long build times probably played a role (while one of the design goals of Kotlin was to be as fast as Java in this regard).
and yes, another important issue is interoperability with Java. it's quite limited with Scala, while Kotlin is fully interoperable (some unavoidable quirks notwithstanding). this was again among Kotlin's chief design goals, and it's of particular importance on Android.
finally - although this is subjective - Scala falls a bit on the "academic" side of languages, while Kotlin has a simpler, friendlier feel to it.
What is the point of using Option, when Kotlin has it built in? All the examples shown in the presentation would be much shorter and more readable with Int? instead of Option.
Kotlin's nullable types are nulls (for the sake of interoperability with Java). If you use a library that doesn't allow for nullability, like - most prominently - RxJava 2, then you can't send an instance of T? down the stream. It'll crash on a null in runtime. If you can't control the source of data, and/or refactoring the entire thing to remove nullability isn't easy, then you could use Optional as a value wrapper for "absent" values.
Note the same problem doesn't exist in the - otherwise very similar - Swift, where the issue of Java interoperability obviously doesn't apply, and conversely, T? types in Swift are syntax sugar for Optionals.
What's the programming language that starts with "b" and finishes with "k" which he was talking about?
Well, maybe I didn't get your sarcasm/joke, but he was talking about Brainfuck
Brainfuck.
Brainf*ck
by Urban Müller
th-cam.com/video/hdHjjBS4cs8/w-d-xo.html
Thanks
so how to type the lambda symbol? :)
In your font settings change it to a fira or some other programming font that has support and then enable font ligatures.
copy and paste from wikipedia
he added a live template which replaces the florin symbol (OPT+F on us-keyboard macs) with the lowercase lambda, but you can also use any other identifier, like "lambda"
Nice slides.... completely impossible to read.
According to him php and python are functional
Please stop calling usage of lambdas functional programming. Even using datatypes from Arrow is not a functional programming.
Please enlighten all of us about what is functional programming!
It IS functional programming. But it's not a PURE functional language.
We can call it "functional programming", but that kind of misses the point of using words. You can do this stuff in almost any language used today. I would argue, that the real difference is between pure functional languages like haskell, nix or elm, and all the other languages. Pure func. languages have referential transparency, that allow the compiler to make guarantees about the code, can give you hints, can make optimizations, and can execute it in the order it wants. To get this to work you can not have variable mutation and you need to carefully seperate side-effectful code from pure code. This distinction is not made in all the popular languages. And to complicate things further, there are even languages like scala, that allow you to optionally seperate these things, so it's the responsibility of the programmer to make it work, but the compiler doesn't really care. Mixing those things in Haskell would result in a compile time error.
Maybe Hello Bessoni Rodrigues is right and we should just view "functional programming" as a style (independently from the language) where you just put maps and filters where you had for-loops previously, but that would be very different to what you get with pure functional programming, so using the term like this is kind of misleading, and the terms "functional programming" and "pure functional programming" would fall into to different categories.
I agree. This is a bit like saying "I touched an object, therefore I do OOP". Imagine if this object is just a backet for some main() function, and within this function you're referring to Console or something, but it's all spaghetti, then yes you're technically dealing with some objects, but you're writing procedural code regardless :)