Anonymous functions work great with currying: fun greet(greeting: String) = fun (name: String) { println("$greeting, $name") } greet("Hello")("Dave") -> Hello, Dave val goodbye = greet("Goodbye") goodbye("Dave") -> Goodbye, Dave Looks more natural than with lambdas: fun greet(greeting: String) = { name: String -> println("$greeting, $name") }
@@markopi64 wow. I was trying to do currying just the other day and you’re right, lambdas look terrible. Anonymous functions definitely look more readable
Wow it really is better; it becomes really clear when we put the alternatives together: fun greet1(greeting: String) = fun(name: String) = println("$greeting, $name") val greet2 = { greeting: String -> { name: String -> println("$greeting, $name") } } fun greet3(greeting: String) = { name: String -> println("$greeting, $name") } `greet1` is just so much easier to read compared to the other two
Though it is not as elegant compared to lambdas, when we have to return something from the function. The "implicit return" feature of lambdas is nice to have in these cases: fun greet1(greeting: String) = fun(name: String): String { return "$greeting, $name" } val greet2 = { greeting: String -> { name: String -> "$greeting, $name" } } fun greet3(greeting: String) = { name: String -> "$greeting, $name" }
Hey, that's fantastic! Yeah, definitely looks cleaner than using lambdas - especially when you'd have to nest them. And the lambda implementation above could be confusing - when I've done that in the past, I've sometimes had to clarify to other developers that it's an expression body with a lambda, rather than a function with a block body. Thanks for sharing, Marko! 🎉
There's a nice rule of thumb for `return` statements for that case with the inline lambda returning the `main` function: a `return` statement always returns the closest `fun`; In the case of the return inside the inlined lambda call, that is the `main` function, and for the anonymous function, it has its own `fun` so it returns there.
A great video again. 10.3.3 Anonymous functions: Local returns by default (Kotlin in action 2nd ed) "A. f. mainly shorten code that has a lot of early return statements, which would need to be labeled when using the lambda syntax." and "despite the fact that an a. f. looks similar to a regular function declaration, it's another syntactic form of a lambda expression."
Thanks Björn! Yeah, I agree with the authors insofar as anonymous functions are also function expressions. But due to the differences in the semantics of the returns, I find it more precise to regard lambdas and anonymous functions as two different ways to write _function literals_, rather than regarding anonymous functions as simply a different syntax for a lambda. Of course, the mental model that's best for each developer is the one that's most helpful to him or her, so if "like a lambda" is helpful to some developers, I wouldn't argue about it.
Great video, I hope someone comments with a use case that you didn't think of, but I'm guessing it's just a case of syntactic sugar. So many people used the lambda syntax that it got workarounds to make it work like an anonymous function, rather than leaving them distinct.
Thanks, Tyler! Yes, I'll be interested to see what use cases are brought up. Specifically wondering whether there are any cases where the compiler has trouble inferring the types of a lambda but where an anonymous function would clear it up. I haven't been able to produce any myself, though.
not true but: - java is academic driven -> programmers are students -> dont trust students, you have to put them under tutelage - scala is community driven -> programmers are teenagers when parents are away over weekend -> house get destoryed but in a creative way - kotlin is company driven -> programmers are costumers that are served and gerrymandered (in a good way) -> if you care about customers, especially in mid life crisis, you dont show them everything you have, otherwise you lose them when they become teenagers without parents ----------- i like that kotlin released me from java imprisonment, but i fear that when you are free, you are free to make more mistakes. Strong antetypes are needed to replace java prohibition by natural kotlin authority in freedom. In this video are a lot of example where authority is needed to make people not to use them without really good reason. When java is right at one thing then it is worship of holy idiomaticism. The big scala mistake was already done, no need to repeat it. But still good to know all those things, there are valid corner cases for every feature.
Hey, thanks for commenting! I hadn't thought about Java/Scala/Kotlin that way before, but I see what you're getting at. Yeah, you might have noticed that I don't often recommend what developers "should do" because it depends on the context. Anonymous functions are an interesting and often-overlooked feature that - like all other language features - should be used with discretion.
@@typealias People should go in playground mode like you do, but don't forget to switch back to production mode, where you write code for others, even when you write it just for yourself. Take the best and skip the rest.
All very interesting, but a double-edged sword. The usefulnes is limited and comments here prove that it is widely unknown. I understand that this may be a product out of genericity and completeness, but it in my book a language is a means of communication between developers. What I write, another needs to understand. If they have to ponder on a piece of code due rarely used idoms, it slows them down and they might miss crucial implications (here: return value logic.) Don't get me wrong, though, it sure is an interesting corner of the language to explore.
Yes, always a good idea to be mindful of the experience and perspectives of other developers on the team (both current and future). If your teammates aren't familiar with an idiom, one option is to avoid it; another is to introduce them to it and see if it's one that makes sense to them and they'd like to adopt. But in any case, development a usually a team effort, and it pays to write code that'll be understood by everyone on the team.
Anonymous functions work great with currying:
fun greet(greeting: String) = fun (name: String) {
println("$greeting, $name")
}
greet("Hello")("Dave")
-> Hello, Dave
val goodbye = greet("Goodbye")
goodbye("Dave")
-> Goodbye, Dave
Looks more natural than with lambdas:
fun greet(greeting: String) = { name: String ->
println("$greeting, $name")
}
@@markopi64 wow. I was trying to do currying just the other day and you’re right, lambdas look terrible. Anonymous functions definitely look more readable
Good point
Wow it really is better; it becomes really clear when we put the alternatives together:
fun greet1(greeting: String) = fun(name: String) = println("$greeting, $name")
val greet2 = { greeting: String -> { name: String -> println("$greeting, $name") } }
fun greet3(greeting: String) = { name: String -> println("$greeting, $name") }
`greet1` is just so much easier to read compared to the other two
Though it is not as elegant compared to lambdas, when we have to return something from the function. The "implicit return" feature of lambdas is nice to have in these cases:
fun greet1(greeting: String) = fun(name: String): String { return "$greeting, $name" }
val greet2 = { greeting: String -> { name: String -> "$greeting, $name" } }
fun greet3(greeting: String) = { name: String -> "$greeting, $name" }
Hey, that's fantastic! Yeah, definitely looks cleaner than using lambdas - especially when you'd have to nest them. And the lambda implementation above could be confusing - when I've done that in the past, I've sometimes had to clarify to other developers that it's an expression body with a lambda, rather than a function with a block body. Thanks for sharing, Marko! 🎉
Why does your every video makes me feel that I know nothing about Kotlin 😂
Kotlin is deep and well designed, imho, so you dont need to go into every corner to get the benefits.
Yes, you can definitely be productive with the more primary features! (Those corners sure are fun to explore, though!)
There's a nice rule of thumb for `return` statements for that case with the inline lambda returning the `main` function: a `return` statement always returns the closest `fun`; In the case of the return inside the inlined lambda call, that is the `main` function, and for the anonymous function, it has its own `fun` so it returns there.
Hey Bruno - wow, that's a fantastic, simple way to remember it! 🎉 Thanks so much for sharing it
I thought I knew everything about Kotlin syntax, but every new video of yours shows me something new. This language is awesome!
Hey, glad I could introduce you to something new, Vemu! Yeah, I really love working in Kotlin!
Best Kotlin content! Thanks Dave
Hey, thanks GB! I appreciate that!
A great video again.
10.3.3 Anonymous functions: Local returns by default (Kotlin in action 2nd ed)
"A. f. mainly shorten code that has a lot of early return statements, which would need to be labeled when using the lambda syntax." and
"despite the fact that an a. f. looks similar to a regular function declaration, it's another syntactic form of a lambda expression."
Thanks Björn! Yeah, I agree with the authors insofar as anonymous functions are also function expressions. But due to the differences in the semantics of the returns, I find it more precise to regard lambdas and anonymous functions as two different ways to write _function literals_, rather than regarding anonymous functions as simply a different syntax for a lambda.
Of course, the mental model that's best for each developer is the one that's most helpful to him or her, so if "like a lambda" is helpful to some developers, I wouldn't argue about it.
I've been writing kotlin since 2018 and never came across this syntax till today :O
Yeah, it's not one that you see out there often!
Great video, I hope someone comments with a use case that you didn't think of, but I'm guessing it's just a case of syntactic sugar. So many people used the lambda syntax that it got workarounds to make it work like an anonymous function, rather than leaving them distinct.
Thanks, Tyler! Yes, I'll be interested to see what use cases are brought up. Specifically wondering whether there are any cases where the compiler has trouble inferring the types of a lambda but where an anonymous function would clear it up. I haven't been able to produce any myself, though.
Loving the content. I think a great future topic could be building in-line DSLs.
Probably most Jetbrains folks not even aware such anonymous fun syntax!
how using inline function allows lambda function to return values ?!
not true but:
- java is academic driven
-> programmers are students
-> dont trust students, you have to put them under tutelage
- scala is community driven
-> programmers are teenagers when parents are away over weekend
-> house get destoryed but in a creative way
- kotlin is company driven
-> programmers are costumers that are served and gerrymandered (in a good way)
-> if you care about customers, especially in mid life crisis, you dont show them everything you have, otherwise you lose them when they become teenagers without parents
-----------
i like that kotlin released me from java imprisonment, but i fear that when you are free, you are free to make more mistakes. Strong antetypes are needed to replace java prohibition by natural kotlin authority in freedom. In this video are a lot of example where authority is needed to make people not to use them without really good reason. When java is right at one thing then it is worship of holy idiomaticism. The big scala mistake was already done, no need to repeat it.
But still good to know all those things, there are valid corner cases for every feature.
Hey, thanks for commenting! I hadn't thought about Java/Scala/Kotlin that way before, but I see what you're getting at. Yeah, you might have noticed that I don't often recommend what developers "should do" because it depends on the context. Anonymous functions are an interesting and often-overlooked feature that - like all other language features - should be used with discretion.
@@typealias People should go in playground mode like you do, but don't forget to switch back to production mode, where you write code for others, even when you write it just for yourself. Take the best and skip the rest.
All very interesting, but a double-edged sword. The usefulnes is limited and comments here prove that it is widely unknown. I understand that this may be a product out of genericity and completeness, but it in my book a language is a means of communication between developers. What I write, another needs to understand. If they have to ponder on a piece of code due rarely used idoms, it slows them down and they might miss crucial implications (here: return value logic.)
Don't get me wrong, though, it sure is an interesting corner of the language to explore.
Yes, always a good idea to be mindful of the experience and perspectives of other developers on the team (both current and future). If your teammates aren't familiar with an idiom, one option is to avoid it; another is to introduce them to it and see if it's one that makes sense to them and they'd like to adopt. But in any case, development a usually a team effort, and it pays to write code that'll be understood by everyone on the team.