How to think about hierarchy in a Functional Programming paradigm?

[danilo-bc]

I've been thinking about how Object-Oriented Programming has organization as a given.

We think about objects and their componentes and can make folders according to a simple object hierarchy. Like how a car has doors, and engine and so on. This makes not only the programming structure clear, but also the source code folders the code where the code will reside.

How can we think about organizing Functional code? Grouping source code folders by an abstract task type and then going down into the hierarchy of functions? Like how create_edge_image can be composed of apply_edge_filter and normalize?

Please feel free to correct me if I'm mistaken about assumptions done here, thanks in advance!

[ursenzler]

We structure our (functional) code by feature.

Our system consists of several sub-systems. Every sub-system is responsible for a dedicated sub-domain. Every sub-system has its own assembly (.NET).
We build an attendance-time system that consists of presence-time, absence-planning, duty-planning, project-time-tracking, organisation-related stuff etc.

Every sub-system contains folders for the different features it provides.
In the organisation sub-system, there is, for example, a folder for features for specifying the organisation chart (the departments and teams of the organisation) and a folder for the features around assignments (who works where in which role).

Each of these folders contains multiple files. A file typically contains the types that model the domain of the functionality this file provides, along with modules that contain functions to operate on the types.

That's how we structure our code, there are probably other ways as well.

[danilo-bc]

Pretty insightful, thanks for your time. It gives me a glance on how Functional projects can be seen. Would you know any Git(Hub) project that follows a similar structure?

[ursenzler]

No, I don't know any project on GitHub following this structure. Most projects on GitHub are libraries, not applications, so the structure is typically a bit different (no sub-system for example).

[valentinajemuovic]

@ursenzler how would you structure a system like e-commerce, which has use cases like place order, cancel order, ship order... What would be the folder/file structure you'd have?

[ursenzler]

Something like this:

[danilo-bc]

Thanks for taking your time to draw this diagram! Since the diagram separates things as sub-systems (things), and the components are grouped by certain slices, AND because each module involves functions coupled to types, this makes me think it's actually an OOP. The subsystem is a higher-abstraction object, the types are primitives (e.g.: a list of products that can be contained in an order) and so on.

What I think would lean towards FP would be the higher-level abstractions representing actions (e.g.: make order, catalogue orders, archive orders), types possibly being ubiquitous and the lower abstraction level files being the steps and transformations towards achieving that higher-level action. E.g.: make_order <- query_cart <- query_payment_info <- authenticate (...)

If not, what's the game-changer between FP and OOP? The lack of a global state (and side effects) when using FP?

[ursenzler]

The diagram is about structure (folders and files). And we use the same structure for our C# (closer to OOP) and F# (closer to FP) code.

A very short definition of OOP vs FP:
OOP = objects interact with each other through methods that may change the object's internal state and trigger further interactions.
FP = functions operate on immutable data. If the function has a side-effect, it's an action.

So we use FP concepts inside the slices to handle our business logic.
And we use OOP concepts for the facades which hold state (over multiple requests / as long as the service is running). This state contains things like connection strings, caches and the runtime structure of our system. These are all performance optimizations so that we don't have to rebuild all of this on every call. We think this is easier than using the FP concept for this (memorization and closures). But conceptionally, they are the same.

What makes this architecture lean more towards FP than OOP is that we expose functionality through facades (functions taking and returning data), not objects.

But this is just what we currently have. We come from a strong OOP background. Haskell'ers would probably structure such a system differently, I guess.

[danilo-bc]

Thanks for the time to explain. Maybe the best scenario is taking the best of both worlds and optimizating. As you mentioned, rebuilding certain structures on every call seems demanding. Also as you mentioned, I wonder how Haskell people would tackle these issues.

Once again thanks for your time and for sharing this, I think I have a clearer picture of how to start shifting towards FP in terms of file organization. I'll leave the question open in case a pure FP programmer wants to contribute with their experience.