https://kotlinlang.org logo
Join Slack
Powered by
Hi! I'm trying to move my team (android developers...
# arrow
j
Hi! I'm trying to move my team (android developers) towards functional programming and Arrow in particular. They don't have much FP experience at all and started by sharing this https://proandroiddev.com/railway-oriented-programming-in-kotlin-f1bceed399e5. Do you have any recommendations or must-reads I could share with them ? Thanks!
❤️ 1
t
Basically everything from Scott Wlaschin 😛 That was my big inspiration. Shameless self promotion; I also made a talk about arrow a while ago (it is outdated now since arrow evolved, but it does show the basic way of thinking) https://vimeo.com/748031479. I also have another talk, but I don't have a recording for that it seems 😞
👍 1
☝️ 1
j
I'm also looking for something showing why FP should be considered rather than traditional OOP. I did introduce and show some ways of using arrow but I don't feel like I have convinced them much
t
Thats what my other talk is for 😛 if you like I could give a free webinar sometime these are the sheets https://tiesvandeven.gitlab.io/empower/)
😍 1
c
I'm also looking for something showing why FP should be considered rather than traditional OOP.
IMO that's the wrong way to approach this. Kotlin is right in the middle of OOP and FP. Arrow helps using more FP, but that doesn't mean you must not use OOP. For example, 
kotlin.coroutines.flow.Flow
is 100% FP, but when introducing it in a codebase, you never try to convince people that FP is better. You just demonstrate the tool, and the tool brings features you can't have otherwise. Think of Arrow in terms of the features it brings. Arrow brings typed errors, Arrow brings resilience mechanisms, Arrow brings deep copy of data classes, etc. It doesn't really matter that pure FP languages prefer this way of designing things: at the end of the day, these are all just new tools you have access to. In Kotlin, you don't have to choose the One Way.
👍 4
t
True 🙂 thats the main thing im discussing in my talk. In the end its all programming and it all needs to solve the same underlying problems. (Also, anything OO does can be defined in FP terms, so in the end it is not that different). It is mostly good to look at the tradeoffs of different approaches and a combination of styles is usually the best approach.

https://www.youtube.com/watch?v=8GWZE2Y2O9E▾

thats also a good talk about this. You can also do functional programming just fine in Kotlin (or Java for that matter) without Arrow 😉
j
@CLOVIS my bad for not expressing me correctly, I meant exactly what you wrote! We are not looking to go away from OOP, I just want to give my team the feeling that FP can help us a lot with some aspects of our work. I started by introducing typed errors with Either, but old habits tend to hold hard. I find myself writing quite often in PRs that this or that could use an arrow feature instead
d
One compelling reason to use FP in Kotlin is error handling - it becomes much less defensive and boilerplate-y, and you can focus on the happy path. If/when errors happen, they're trapped in convenient values which you can process later. We have some examples in video form here:

https://youtu.be/C0B44WBJJmY▾

or in written form here: https://blog.rockthejvm.com/functional-error-handling-in-kotlin-part-2/
❤️ 1
c
You have to define what "error handling" means, then. Using 
Either
everywhere is more verbose than using exceptions. Using 
Raise
is about the same amount of code, but really, 
Raise
is just a nicer API for 
throws
in Java, there's nothing particularly FP about it.
Also, mandatory "never use 
runCatching
for error handling, it's not designed for it, and it will cause enormous bugs down the line, including zombie coroutines"
j
Has anyone an opinion on this https://xebia.com/academy/nl/training/functional-programming-with-arrow/ maybe I should start a new thread about it instead?
t
Well, the creator of Arrow works there 😛 so it might be decent
j
That's why I asked 😂
m
Open in Slack
PreviousNext
Powered by