Just finished migrating The Kotlin Primer onto a <...

# feed

[Gabriel Shanahan]

Just finished migrating The Kotlin Primer onto a brand new website. The Primer is an opinionated guide to the Kotlin language, and has successfully been used to migrate a Java-centric organization to Kotlin. It was previously hidden behind a paywall on Medium, but is now public for all to use. Check it out, and let me know what you think!

[Robert Jaros]

Impressive work! Congratulations!

[Robert Jaros]

If I could suggest an improvement, it would be better to prevent the side menu from scrolling to the top after each click.

[Gabriel Shanahan]

Agreed, it's already on my todo-list, along with 4 other improvements!

[Jacob]

https://www.kotlinprimer.com/standard-library/sequences/iterable-vs-sequence-vs-java-stream/#46f7 Another thing streams have that sequences do not, is a close method

[Jacob]

https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#error-handling-style-and-exceptions I'm of the opinion that everyone is using result wrong :)

[Gabriel Shanahan]

> Another things streams have that sequences do not, is a close method
Thanks for the tip, I honestly never realized that Stream was closable, and I can't quite wrap my head around the motivation for it (but that's probably because I haven't spent any time actually using it IRL).

> I'm of the opinion that everyone is using result wrong 🙂
There's a large discussion to be had about this, my frank TL;DR is "kotlin.Result show you a path that you should walk, but not using kotlin.Result". My next big target is to do a series on Arrow, and this is basically all it's going to be about. I do want to revisit the sections on Result though, and a) write some more about why exceptions are bad, and b) write some more about how using kotlins Result implementation (which is basically a butchered Either implementation) also isn't ideal.

[Benoît Liessens]

Looking forward to that elaborate discussion on kotlin.Result 💪

[Cies]

Looking fwd to that as well. I think my team understands this (custom result objects over exceptions). But it's nice to have that explained in the primer. (I think Duncan's "Java to Kotlin Porting" book covert this as well.

[Cies]

I found this chapter's conclusions and discussions a little "thin". I'd not go as far as to make grand conclusions for all of FP and OOP: it violates your goal of making the primer "pragmatic".

My take on the points this chapter should make:
• Kotlin is in the basis an OOP-lang (it support classes+objects), and this is a requirement for tje language as it is set out to provide real-damn-good Java interop.
• Classes (and thus objects) combine data and functions together; in FP data and functions are kept separate.
• Since Java 8 a lot of FP-lang features have been added to Java, Kotlin goes a lot further.
• Kotlin provides FP programming support where it makes sense and to the extend it is possible (since the JVM is an important compile target some more advanced FP-lang features are not part of the language; notably: special handling of pure functions).
• The Arrow library adds more FP-lang features to Kotlin.
"Structure programs using OOP, implement behaviors using FP" -> A large part of why idiomatic Kotlin is different from idiomatic Java is in the use of FP techniques. Use of exceptions make using FP-techniques hard, and are thus not so idiomatic in Kotlin. We structure our code using OO when we have to, usually due to interop with Java. Otherwise FP structuring (data classes and other data defs separate from functions; instead of lumping them together in classes) is preferred. We use FP-techniques where ever it makes sense, while not sweating the use of OOP-techniques when more pragmatic.

[Klitos Kyriacou]

In Sequences vs Iterables the line following val instantFilterResult = mutableListOf<Post>() should be changed from for(post in this) { to for(post in authorFilterResult) {. (playground)

[Gabriel Shanahan]

Hey @Cies, thanks for reading through, and for the feedback! I'm delighted it's provoked a conversation, and I'm grateful you guys are spending time with it. Let me start off by saying that there's a lot more that I want to add to the topic of FP, and in fact, this is going to be the next big topic I want to write about, including the things I mentioned above, and some of what you mention as well. I agree that the treatment in this chapter is "shallow" as you said, and more could, should, and will be written on that topic. That being said however, I do stand by the fundamental message of the article - structure programs using OOP, implement behaviors using FP. Having read your message a couple of times, I confess I'm unsure if you're actually disagreeing with it or not, which is preventing me from responding further. Are you?

@Klitos Kyriacou Good catch! Thank you for the check, fixed 🙂