Skip to content

Conversation

@patrickwilmes
Copy link
Contributor

No description provided.

Copy link
Contributor

@abishekanthony07 abishekanthony07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All in all the Blog is really expressive and on point!
I have mostly added suggestions to Kotlin code. Feel free to challenge them!
Thank you Patrick!

> **"Every tool is a lens. The more lenses you collect, the more truth you see."**

Most experienced developers live and breathe **object-oriented programming (OOP)**.
We design systems in terms of entities, behaviors, and hierarchies; we reason about state, lifecycle, and encapsulation. It works beautifully—until it doesn’t.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor

Write each sentence in a new line. Helps to pin-point findings.

You find yourself wishing you could express _what_ you want, without micromanaging _how_ it happens.

That’s where **functional programming (FP)** enters — not as a rival philosophy, but as a complementary one. FP isn’t about writing math puzzles or memorizing category theory.
It’s a practical way to make logic predictable, composable, and testable.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It’s a practical way to make logic predictable, composable, and testable.
It’s a practical way to make business logic predictable, composable, and testable.

It’s a practical way to make logic predictable, composable, and testable.
Instead of modeling _objects that do things_, FP focuses on _functions that transform data_.

This article helps experienced OOP developers understand and apply FP concepts using **Kotlin**, without detouring into abstract theory. But the same principles and techniques can
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This article helps experienced OOP developers understand and apply FP concepts using **Kotlin**, without detouring into abstract theory. But the same principles and techniques can
This article helps experienced OOP developers understand and apply FP concepts using **Kotlin**, without detouring into abstract theory.

Instead of modeling _objects that do things_, FP focuses on _functions that transform data_.

This article helps experienced OOP developers understand and apply FP concepts using **Kotlin**, without detouring into abstract theory. But the same principles and techniques can
also be applied to any Java code base (Java 8+).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
also be applied to any Java code base (Java 8+).
The same principles and techniques can also be applied to any Java 8+ code base.

```kotlin
fun <T, R> Collection<T>.mapToSet(mappingFunc: (T) -> R): Set<R> {
val targetSet = mutableSetOf<R>()
forEach { targetSet.add(mappingFunc(it)) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
forEach { targetSet.add(mappingFunc(it)) }
this.forEach { targetSet.add(mappingFunc(it)) }

just for clarity ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe shortly explain that the scope changes in extension function to the type which we extend ;)

class OrderService {
fun processOrder(order: Order): Result<Order> =
validateOrder(order)
.map { applyDiscount(it, 0.1) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.map { applyDiscount(it, 0.1) }
.map { applyDiscount(0.1) }

fun processOrder(order: Order): Result<Order> =
validateOrder(order)
.map { applyDiscount(it, 0.1) }
.flatMap { saveOrder(it) } // Side effect wrapped in Result
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.flatMap { saveOrder(it) } // Side effect wrapped in Result
.flatMap { save() } // Side effect wrapped in Result

}
```

A backend service might model its domain in OOP but express its data transformations functionally—clean logic, explicit effects.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A backend service might model its domain in OOP but express its data transformations functionally—clean logic, explicit effects.
A backend service might model its domain in OOP, but express its data transformations functionally—clean logic, explicit effects.

When OOP gives us _nouns_, FP gives us _verbs_. Together they form the full grammar of software.

The goal isn’t _purity_, but _clarity_.
Start small: use `val` instead of `var`, extract pure functions, embrace `map`, `filter`, and `flatMap`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Start small: use `val` instead of `var`, extract pure functions, embrace `map`, `filter`, and `flatMap`.
Start small: focus on **immutability** (`val` instead of `var`), extract pure functions, and embrace `map`, `filter`, and `flatMap`.


The goal isn’t _purity_, but _clarity_.
Start small: use `val` instead of `var`, extract pure functions, embrace `map`, `filter`, and `flatMap`.
Over time, you’ll find that FP principles don’t just make your code safer—they make it _simpler_.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Over time, you’ll find that FP principles don’t just make your code safer—they make it _simpler_.
Over time, you’ll find that FP principles don’t just make your code safer—they also make it _simpler_.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants