# fp Published articles for fp. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Object-oriented or functional? Two ways to see the world DevFeed: [Object-oriented or functional? Two ways to see the world]() Original publisher: [Read original article]() Published: 2022-08-18T00:00:00Z Content type: opinion Language: en Sources: [Kt. Academy]() Topics: [Functional programming](), [Object-oriented programming (OOP)](), [Programming]() Tags: [fp](), [functional](), [immutability](), [inheritance](), [object-oriented](), [oop](), [polymorphism](), [recursion](), [workshop-learning-programming]() ### AI overview This opinion article compares object-oriented programming and functional programming as ways of thinking about program design, rather than merely collections of features. It uses different ways of viewing a bedroom--as objects or actions--to illustrate the distinction while acknowledging that modern languages commonly support both styles. ### Source excerpt The difference between the OOP and FP paradigms is deeply rooted in how we see the world. A few words on the philosophy of both approaches. ## Exploring Kotlin's Context Receivers DevFeed: [Exploring Kotlin's Context Receivers]() Original publisher: [Read original article]() Author: Simon Vergauwen Published: 2022-02-17T00:00:00Z Content type: article Language: en Sources: [nomisRev]() Topics: [Kotlin](), [ide](), [context]() Tags: [compiler](), [dsl](), [effect](), [extension-function](), [fp](), [function](), [ide](), [kotlin](), [scope-functions](), [suspend]() ### AI overview A tutorial on Kotlin Context Receivers, introduced as a preview in Kotlin 1.6.20-M1. It explains how additional receivers work, how the compiler handles them, and how they can support scope-based programming patterns such as effect handlers and logging contexts. ### Source excerpt Last week a long awaited feature was released as a preview in Kotlin 1.6.20-M1. In this blogpost we're going to explore what Context Receivers are, and some benefits and patterns they'll enable. To try it out in your IDE, follow this guide ## Modelling UI State on Android DevFeed: [Modelling UI State on Android]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2021-01-29T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [Android](), [android-development](), [Kotlin](), [Data structures](), [Development]() Tags: [android](), [android-development](), [cardinality](), [data-class](), [data-structure](), [fp](), [functional](), [kotlin](), [livedata](), [rxjava](), [sealed-class](), [stateflow](), [types](), [ui](), [viewmodel]() ### AI overview This article explains how to model Android UI state in Kotlin using data classes and sealed classes. It connects types with sets and cardinality, then describes product types and sum types as tools for representing valid application states. ### Source excerpt The recommended approach from Google for Android development is holding the UI state in a ViewModel and having the View observe it. To achieve that one can use LiveData, StateFlow, RxJava or a similar tool. But how to model the UI state? Use a data class or a sealed class? Use one observable property or many? I will describe the tradeoffs between the approaches and present a tool to help you decide which one to use. This article is heavily inspired by Types as Sets from the Elm guide, a large part is a translation from Elm to Kotlin. Photo by Marc-Olivier Jodoin on Unsplash Types as sets By Making Data Structure we can make sure the possible values in code exactly match the valid values in real life. Doing that helps to avoid a whole class of bugs related to invalid data. To achieve that, first we need to understand the relationship between Types and Sets. We can think of Types as sets of values, they contain unique elements and there is no ordering between them. For example: Nothing - the empty set, it contains no elements Unit - the singleton set, it contains one element - Unit Boolean - contains the elements true and false Int - contains the elements: ... -2, -1, 0, 1, 2 ... Float - contains the elements: 0.1, 0.01, 1.0 .... String - contains the elements: "", "a", "b", "Kotlin", "Android", "Hello world!"... So when you write: val x: Boolean it means x belongs to the set of Boolean values and can be either true or false. Cardinality In Mathematics, Cardinality is the measure of "number of elements" of a Set. For example the set of Boolean contains the elements [true, false] so it has a cardinality = 2. Let's take a look at the cardinality of the sets mentioned above: Nothing - 0 Unit - 1 Boolean - 2 Short - 65535 Int - ∞ Float - ∞ String- ∞ Note: The cardinality of Int and Float is not exactly infinity, it's 2^32 however that is a huge number. When building apps, we use built-in types and create custom types using constructs like data classes and sealed classes. Product ## Side Effects and Composition DevFeed: [Side Effects and Composition]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2019-08-13T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [Functional programming](), [Programming](), [Code](), [Dependency injection](), [SDKs](), [API]() Tags: [api](), [arrowkt](), [code](), [dependency-injection](), [fp](), [functional](), [functional-programming](), [kotlin](), [programming]() ### AI overview This tutorial uses a coffee-shop payment example to explain side effects, testability, dependency injection, composition, and referential transparency in functional programming. It shows how extracting payment logic into a Payments object enables mock implementations for tests, and how reusing single-coffee logic for multiple coffees can avoid charging a credit card multiple times. ### Source excerpt Photo by Ryan Yoo on Unsplash Functional Programing is amazing. It limits the things you can do (no nulls, no exceptions, no side effects...) and in return you get some benefits. Some benefits of FP are easy to explain and some not so much. I have been playing with FP for more than a year and only few weeks ago, when I started reading Functional Programming in Scala, I found an amazing example the benefits of pure functions. The problem Building a software for a Coffee Shop. For the initial MVP the requirements are: Sell coffee Pay with a card so the first draft of the code looks like this: import coffee.* fun buyCoffee(cc: CreditCard): Coffee { val cup = Coffee() cc.charge(cup.price) return cup } The buyCoffee function receives a CreditCard as an input and returns a Coffee as an output. It creates a Coffee object, then executes a charge and returns the Coffee object. Testability The call cc.charge uses an SDK/API to talk to the credit card company. It involves authorization, network call(s), persisting a record in the DB. The buyCoffee function returns a Coffee and the charging happens on the side hence the terms "side effect". The side effect makes buyCoffee hard to test in isolation. It would be nice (and cheaper) to run tests without actually talking to the credit card company and doing an actual charge. One could also argue that a CreditCard should not know how it's being charged. The testability problem can be fixed using Dependency Injection. fun buyCoffee(cc: CreditCard, p: Payments): Coffee { val cup = Coffee() p.charge(cc, cup.price) return cup } The logic of charging the credit card is extracted into the Payments object. In production code the real Payments implementation is used and a mock version is injected for tests. New requirements After a few weeks in business new requirements arrive. Some people buy more than one coffee so the next version of the software has additional requirements: Buying N coffees Single charge per Credit Card Composition The pro ## Functional Hangman in Kotlin with Arrow (part 2) DevFeed: [Functional Hangman in Kotlin with Arrow (part 2)]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2018-12-25T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [Kotlin](), [Programming](), [IO](), [Error Handling]() Tags: [arrowkt](), [code](), [error-handling](), [exception-handling](), [fp](), [functional](), [io](), [kotlin]() ### AI overview This tutorial explains the second part of converting a functional Hangman game from Scala with ZIO to Kotlin with Arrow. It replaces a hard-coded IO data type with a polymorphic design using Kind and introduces MonadDefer to represent capabilities such as lazy evaluation, exception handling, and completion with a result. ### Source excerpt Converting a Functional Hangman game from Scala (ZIO) to Kotlin (with Arrow) was a nice exercise. I enjoyed working on it and I learned a lot. When I asked for feedback on the #arrow channel, one of the maintainers, Leandro had an interesting suggestion. Instead of hard-coding the data type IO I should try and make the program polymorphic and use Kind instead. That means writing the code focusing on the domain logic, using abstractions, and deferring the decision for the concrete data type like IO or Single (from RxJava) until the main function. The journey I was not familiar with that style of programming so I used this example from the excellent Arrow documentation as a guide. Writing to the the console In the previous article I used IO to interact with the console. IO represents an operation that can be executed lazily, fail with an exception (the exception is captured inside IO), run forever or return a single A. Let's take a look at the original implementation: fun putStrLn(line: String): IO = IO { println(line) } // Usage in main() putStrLn("Hello world!").unsafeRunSync() putStrLn is a function that take a String and return a IO. IO takes a lambda that is lazily evaluated at the end of the world, when we call unsafeRunSync(). If we want to achieve the same thing with Single we could use Single.fromCallable wrap our lambda and evaluate it in the main function when we call subscribe(). fun putStrLn(line: String): Single = Single.fromCallable { println(line) } // Usage in main() putStrLn("Hello World").subscribe() Here bothIO and Single have something in common. A set of capabilities like: lazy evaluation, exception handling, and running forever or completing with a result of type A. IO and Single do a lot more, but for this use case, we want something as simple as possible that has the same capabilities. There is a type-class in Arrow that can do just that and it's called MonadDefer(more info). After a few iterations, and feedback from th ## Functional Hangman in Kotlin with Arrow DevFeed: [Functional Hangman in Kotlin with Arrow]() Original publisher: [Read original article]() Author: Stojan Anastasov Published: 2018-11-11T00:00:00Z Content type: tutorial Language: en Sources: [Stojan Anastasov's blog]() Topics: [Kotlin](), [Functional programming](), [IO](), [Scala](), [Coroutines](), [Code]() Tags: [arrowkt](), [code](), [coroutines](), [fp](), [functional-programming](), [io](), [kotlin](), [programming](), [scala]() ### AI overview A developer describes rewriting a functional console Hangman game from Scala ZIO in Kotlin with Arrow. The article compares their IO abstractions, console I/O, and approaches to for-comprehension-like code, noting that the implementations are not fully equivalent. ### Source excerpt A few days ago I run into this blog post about implementing a console Hangman game using Scala ZIO. The blog post is based on this talk delivered by John De Goes, for the Scala Kyiv meetup, where he codes a console Hangman game using functional programming. After I saw the post I was curious how the code would look like written in Koltin with arrow so I decided to try and write it. You can find the result here. I am still learning functional programming so I asked for feedback from the arrow maintainers on the kotlinlang slack workspace. They were very helpful and I made a few improvements based on their feedback. Key differences I would like to point out that the programs in Scala and Kotlin are not 100% equivalent. There are both differences in the language and the functional libraries used. The IO monad In Scala ZIO IO[E, A] describes an effect that may fail with an E, run forever, or produce a single A. In the Kotlin version I am using IO from Arrow. IO describes an effect that can fail with Throwable or produce a single A. Both type classes produce an A. The key difference the error. In Scala ZIO you can use any error type or even Nothing to indicate the program never ends. In Arrow the E type is always Throwable so you don't have to specify it. Reading and writing from the Console Scala ZIO comes with built in primitives for interacting with the console. In the Kotlin version I had to implement the readStrLn and putStrLn functions myself. 1 2 3 4 5 fun putStrLn(line: String): IO = IO { println(line) } fun getStrLn(): IO = IO { readLine() ?: throw IOException("Failed to read input!") } For comprehensions For comprehensions are built into the scala language. Unfortunately Kotlin doesn't have the same feature. But Kotlin has Coroutines so the Arrow team built Comprehensions over coroutines which can be used in a similar way to make the code more readable. 1 2 3 4 5 6 7 8 9 10 //Scala with For comprehensions val hangman : IO[IOException, Unit]