Michał Płachta

Author
+ Follow
since Oct 25, 2022
Merit badge: grant badges
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Michał Płachta

Completely agree with Venkat. I'd add one more thing: make sure the language you choose supports a similar style and syntax to what you are used to. This will allow you to focus on the "functional paradigm shift", not the syntax.

That's why using Kotlin or Scala is a good choice to learn FP if you are a Java dev.
1 year ago
In functional programs you usually model state as a stream of immutable values (state0, state1, state2). Functions just take this immutable value and return another immutable value that represents the result (this may be a new immutable value representing state!).

The whole idea of FP is to push impurity out of your core program. This means that storing state (by calling APIs, or saving in a DB) is done outside of the functional core.

Let me know if that makes sense.
1 year ago
@Burk

I completely agree with Venkat here. I don't know if his book includes Testing/TDD. However, if you haven't seen it already, a few months ago we were discussing "Grokking Functional Programming" where there is a whole chapter dedicated to testing and TDD in functional programs
1 year ago
Congratulations! I hope you will learn a lot and have fun with the book

Thanks for all the great questions, everyone! I really enjoyed it.
2 years ago
Yes, a function that takes a String and returns an Int is represented as Function<String, Integer> in Java. It can be a normal function parameter.
2 years ago
Yes, but wouldn't that mean that you will need three different classes (with different implementations)?

Usually, we can't hide things like that, no matter if OOP or FP. If the business feature requires three different strings based on some configuration, we will need to have three different strings.
2 years ago
We can see the impact functional programming has on web application development. React.js for example started using the Virtual DOM technique by allowing developers to define a pure function from state to a DOM representation. No mutations allowed!

Before this huge change happened, web developers needed to mutate DOM themselves which caused all kinds of problems, e.g., mutating (and replacing) the same part of the DOM by different jquery functions.

This is exactly what FP techniques do for us. The mutations and side effects are done in a single place which is abstracted away from the developer who only works on immutable "representations". This way we can all focus on business features and can't foot gun ourselves that easily.

We can learn from it in backend applications as well. Instead of calling a web service endpoint by opening a socket, we just return an immutable value representing the call and the result it should return in the future. We then can work with this value, transform it, and compose it with other values, potentially representing more web service calls or DB calls. A different module in our application can then "interpret" these values into real calls (and can do it in a more optimal way, just like the React engine can do DOM mutations in an optimal way).

We explain all these things and how to achieve them in practice in the book
2 years ago
Monad is a type that has a flatMap function plus a way to construct a value of this type:

- List has flatMap and empty List constructor
- Option has flatMap and empty constructor
- Either has flatMap and empty constructor
- ...

They are all monads (or monadic types).

One catch here is that the flatMap and the constructor need to be implemented in a specific way: they need to satisfy the three laws (left identity, right identity, and associativity)
2 years ago
Monads are very useful and they are hard to misuse in a way singleton is being misused.

However, I'd say they are more of a "low-level" mechanism for functional programs. They come from a mathematical background and have laws and all that, but they are also immensely practical.

My take is that until you are just using monads that are built-in or provided in a library, you don't need to know how they are mathematically constructed. Just like to use garbage collection you don't really need to understand GC internal implementations. It doesn't mean it's not worth it, far from it! It just means you would probably not want to teach garbage collector implementation details in the beginner Java book ;)

Many programmers are productive without knowing the intricacies of GCs—they are fine with just knowing how it works from the outside. The same can be said about functional programmers: they can be productive by just using the flatMap function on their Lists, Options, Eithers, IOs, Resources. And both groups are always welcome to dive deep and learn obscure GC details or Monad laws that make the flatMap function so useful.

Going back to your original singleton example. The analogy for monads would be creating your own monad class (for example, specific to your business domain), not just using provided ones. In this sense, you need to learn the math to do it correctly! The good news is that you rarely need custom monads and even if you do, you can do it in two or three different ways that don't include implementing your own monad.
2 years ago
Definitely, this was a hard process, can't compare it though because it's my first book

However, I really appreciate all the thought we put into choosing topics because now answering questions like this one about monads is very enjoyable

2 years ago
Great question!

When you pick up a book with "functional programming" in its title you are expecting the monad in the table of contents. I get that but at the same time, I feel it's not helping the cause. I mean, what's the objective?

When I started writing the book, my objective was that after finishing it, a reader is able to implement and maintain a real-world functional application in a team setting. And I chose every topic, every concept, and every example carefully, dropping anything that didn't help the main objective. And, as it turned out, monad was one of them.

It was completely fine to just say that some types have the flatMap function and no matter what type, the function behaves similarly. That's it... There are more functions that are defined on multiple types and behave similarly: map, flatten, orElse, sequence, traverse, foldLeft, foldRight, size, count, contains, forall, exists, and so on. Some of them are coming from category theory and can be named accordingly, but would that be helpful for a beginner functional programmer?

2 years ago

Campbell Ritchie wrote:Thank you. And you are adding error handling and testing
All is well until you print the final result because that is a side effect



Yes that's true! And we also talk about that in the book. The objective is to have almost all important code in the "functional core" which is completely pure. We of course need side effects but it's very useful to have them separated in the codebase and there are FP techniques that help us with that.  
2 years ago
Yes, exactly! We start with writing Java functions that operate on Strings in chapter 1. Then, chapter after chapter we learn new things and do a lot of exercises. By the end of the book, we know enough to write a full-blown functional application that works with I/O, has excellent error handling, acquires and releases resources safely, and is thoroughly tested in chapter 12.
2 years ago
Wow thanks Bert!!! ❤️

It wouldn't be possible without you. I am really proud of how the book turned out. And people seem to love it as well which is a great feeling.

What's next, I don't know yet, but I definitely don't feel like writing another one. I heard that this feeling changes after 6 months or so, is that true? ;)
2 years ago

Campbell Ritchie wrote:Would you regard a search of a conventional database as a function? If you do the same search twice you should get the same result if nothing else has changed.



You may treat it as a function but it's definitely not a pure function, because there are side effects involved (you are querying over a network, the DB state can change, the host computer may change, and so on). That's why we use the IO type for such functionalities. The IO type is an immutable value that describes side-effectful things. We introduce IO later in the book (chapter 8) so there are some foundational things you need to learn to grasp it but it's very powerful and helps with the design a lot.
2 years ago