WIP: Towards pure FP using IO Monads and Kleisli composition

[sentenza]

The objective is to refactor the current program in order to be executed only at the end of the world and to enclose the IO side effects into an IO Monad, while composing functions using Kleisli Composition.

Changes proposed in this Pull Request:

• Split the project into three subprojects:
  • End of the World
  • Application
  • FP library
• Try to create a point-free program (Tacit programming)
• Describe the program using function composition
• Execute the program only at the end of the world
• Define Monad and KleisliComposition

Notes

Considerations/Implementation Details (optional)

Give enough context to reviewers and specify focus of the changes.

Test Instructions

Explain what was and wasn't tested. Justify why there were no tests.

QA

Screenshots/Screencasts (optional, but should be included when relevant)

[ivanopagano]

If I may say, I'm generally unconvinced about the gained benefits of defining custom versions of the popular combinators/datatypes.

I'm not trying to criticise just for the sake of it. I'm reasoning that the usefulness of having a library that provides such functional affordances is in the breadth of such apis. While educationally very useful, re-writing custom versions of Kleisli or function composition, tailored for the specific use cases, doesn't actually payback wrt the added complexity and implementation cost.

Using an fp lib like "cats/scalaz" provides a very broad spectrum of previously unavailable functionalities, that concurs to enable a consistent and terse syntax to powerfully combine operations. I think that those are necessary to express a side-effecting program in such a way that it's worth paying the price of the added abstraction.

Just adding food for thought, please consider how the proposal might actually make it less clear what is the real benefit of going to such length, only to express something that seemed so simple before. The risk is that people trying to approach fp, could be actually unconvinced by all the added ceremony with no blatantly clear benefits.

[sentenza]

If I may say, I'm generally unconvinced about the gained benefits of defining custom versions of the popular combinators/datatypes.

First things first let me thank you for the time you have spent going through this PR. As you can see in the title of the PR this is a Work In Progress, and its purpose is just educational for now. My idea was to introduce a clear distinction between the description of the program and its execution.

I'm not trying to criticise just for the sake of it. I'm reasoning that the usefulness of having a library that provides such functional affordances is in the breadth of such apis. While educationally very useful, re-writing custom versions of Kleisli or function composition, tailored for the specific use cases, doesn't actually payback wrt the added complexity and implementation cost.

I know that this is not really useful in a production environment and I wouldn't use this approach in a real project, but quite the opposite.

Using an fp lib like "cats/scalaz" provides a very broad spectrum of previously unavailable functionalities, that concurs to enable a consistent and terse syntax to powerfully combine operations. I think that those are necessary to express a side-effecting program in such a way that it's worth paying the price of the added abstraction.

Keep in mind that a development rule of this project is that

Each implemented piece of code must not have any external dependency

I like the approach expressed in Cats more than anything else, and my idea was actually to introduce some of the fundamental concepts of that library through a direct link from the simpler code that you can find in here. I think that introducing the Category Theory using simple examples helps a lot in the process of switching from the imperative to the functional paradigm.

The real aim of this little project is to bring more people to Scala and FP. That's its sole purpose, so there's no chance to use it apart from in a well confined space made for learning some principle which can be then extended.

Just adding food for thought, please consider how the proposal might actually make it less clear what is the real benefit of going to such length, only to express something that seemed so simple before. The risk is that people trying to approach fp, could be actually unconvinced by all the added ceremony with no blatantly clear benefits.

That's a very good point indeed. I don't really want to scare people, and I can leave this piece of code out of scope. I also think that these subjects are hard to grasp for a newcomer at first, and that it takes time and effort to understand why we should embrace the functional paradigm and its ceremonies.

[ivanopagano]

Thanks for the answer I think I got your point better now.

I'm conscious of the problem with FP in Scala that justifying the effort undertaken on a very basic use cases becomes hard, yet using the full power of all combinators and type classes becomes overwhelming for those unfamiliar, thus keeping people at a distance in both cases. For the first it seems that unneeded complexity is introduced for little gain, for the second there are too many things to learn at once which turns into an impossible task. I guess it's hard to strike a good balance there.

[sentenza]

I'm conscious of the problem with FP in Scala that justifying the effort undertaken on a very basic use cases becomes hard, yet using the full power of all combinators and type classes becomes overwhelming for those unfamiliar, thus keeping people at a distance in both cases. For the first it seems that unneeded complexity is introduced for little gain, for the second there are too many things to learn at once which turns into an impossible task. I guess it's hard to strike a good balance there.

I totally agree on that.