Fundtional design

[Campbell Ritchie]

How does designing a functional application differ from designing an objecct‑oriented one?

[Alexander Granin]

Campbell Ritchie wrote:How does designing a functional application differ from designing an objecct‑oriented one?

This is actually a great question, and I'm quite interested in showing the difference. This is why I have a talk "Functional Declarative Design: a counterpart to Object-Oriented Design". It was a talk for Manning / Twitch, and I hope they'll move it to YouTube soon. For now it's available by this link:

https://www.twitch.tv/videos/1150160792

You can check out my slides: https://docs.google.com/presentation/d/1F2euJMIrnGe5Ii53a6C19YrpYkhsbl1chXewqWQAXuY/edit?usp=sharing

The question is too broad, so key differences:
- Pure/impure layering. We don't put that much effort in keeping our OOP applications separated into these two layers. In FP, we do this all the time
- eDSLs in FP are much more preferred than in OOP (although everything can be seen as a kind of eDSL)
- FP applications can have many different architectures although the 3-layer architecture is quite popular. We have our own tools for it: Service Handle pattern, Free monads, Final Tagless/mtl, ReaderT pattern and some others
- There are OOP interfaces in Java and C#, and I consider Free monads to be the best analog to OOP interfaces. Free monads are functional interfaces having additional properties (eg you can build good monadic languages and frameworks with Free monads)

You'll find more interesting points in my talk.

[Campbell Ritchie]

Thank you

[Junilu Lacar]

Another perspective (which I picked up from a different book) is to separate concepts along three lines:

1. Actions (have side-effects)
2. Functions (don't have side-effects)
3. Data

These are high-level concerns, of course. The idea is that side-effects are what make programs useful. Functions that don't have side-effects are what make programs simpler and easier to maintain. When you separate these two things from the data that's being managed and manipulated, then you can write practical functional programs.

I guess my question to our guest author is whether this perspective about separation of concerns in functional programs is discussed in his book.

[Alexander Granin]

Junilu Lacar wrote:Another perspective (which I picked up from a different book) is to separate concepts along three lines:

1. Actions (have side-effects)
2. Functions (don't have side-effects)
3. Data

Yes, of course, separation of concerns is one of the central topics of the book, although I have different terminology. It corresponds to your points but is closer to the common terminology.

1. (Pure; interfaces layer) Embedded domain-specific languages / pure functional interfaces / pure actions (point #2 in your list)
2. (Pure; domain layer) Domain model and business logic on top of the interfaces layer (point #3 in your list)
3. (Impure; implementation layer) Implementation of eDSLs and functional interfaces (point #1 in your list, kind of)