# arrowkt Published articles for arrowkt. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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]