Should functional be the way to go?

github logo ・1 min read

This question is directed towards more of the practical side of both Frontend and Backend programming.

I have recently picked up Functional Programming and I am not sure if I should actually start building apps in it.

Also I don't just refer to adding functional sprinkles on the top with reduce and map but to actually build on functional paradigm through lambda calculus and the shared concepts(Type, Category Theory) around it.

I am aware that it makes sense in some fields proven by Scala, Clojure and such but I am not sure about if web projects should go Functional even if with some impurities?

Some advice or input will be helpful.

twitter logo DISCUSS (12)
markdown guide
 

I have a close friend who is a pure-functional advocate because he writes code that moves millions of dollars around every day (high-frequency trading algorithms), and he can't afford for there to be any mistakes whatsoever. Everything he writes is a tour-de-force in category theory.

However, for both backend and frontend programming, here are some things to consider:

  1. Time to market and ease of maintainability are usually higher priorities than correctness, as there tends to be a lot of forgiveness from real users around low-severity bugs.

  2. Contemporary programming languages for both backend (e.g. Node, Python, Ruby) and frontend (e.g. Javascript, Swift, Kotlin) are all multi-paradigm so you are free to use whatever hybrid of programming techniques that you need for your problem.

  3. Choices in technologies will tend to drive you toward certain paradigms. For example, if you go serverless you'll be going Functional; If you use Apple's Cocoa framework you're going Object Oriented.

  4. The problem you are solving should dictate the paradigm you choose: define the problem then pick the paradigm that best solves it.

  5. Most people abandon Object Oriented programming because they never invest the time to learn it. Functional is relatively easy to understand, but Object Oriented Programming can take years of experience before you know if the paradigm is appropriate.

  6. "Pure" or "Impure" don't tend to be a primary concern in practice. "Done" and "Good Enough" tend to be more useful goals.

For what it's worth, I write mostly in a Functional style for both Frontend and Backend unless I see a problem best solved through another paradigm. When the time comes to switch paradigms I know why I'm making the switch and what the tradeoffs are. I never worry about purity, only about effectiveness: am I solving the problem in the best way, where "best" is some combination of accuracy and cost.

 

Makes sense thanks for the insight, and analysis of problem is probably the best way of deciding the method.

 

Use the right tool for the job. In general I think you can write most frontend and backend apps functionally, but not per se with category theory. I think there’s a lot of space between sprinkling (just using map and reduce) and going full mathematical :)

Functions as first class citizens and immutability, gets you a long way.
E.g React lends itself well for functional frontend too, also works with f#/fable.

Perhaps some interesting reads for functional domain modeling:
fsharpforfunandprofit.com/rop/
fsharpforfunandprofit.com/ddd/

 

Thanks both seem to be an interesting read bookmarked.

 

What about Elixir/Phoenix? It's a beast of a language and framework....and is built on a VM that has been keeping networks up and running for a lot longer with a lot higher availability than anything else. It's kind of amazing that a highly concurrent/asyncronous/distributed problem such as web development gets thought of as a poor choice for functional programming....

 

I agree that Elixir is a performant language with it's isolate processes and Erlang VM which is known for it's fault tolerance.

But it is a different kind of an investment compared to Frontend. What if the task is to build a simple SPA, will Functional Programming still be viable.

Personally I think it's better cause it will allow for reliable code that does not need heavy testing and would be faster/simpler to maintain.

But I don't know what will be the approach in a professional environment.

 

Functional programming is a mixed bag.

If I look at systems like Processing I think it would probably be wiser to go more in a functional direction than throwing a bunch of side-effect heavy "procedures" at people who barely get programming at all. I mean most people understand the Excel way of programming and it is very functional.

On the other hand, I see stuff like Haskell and PureScript and think this is too mathematic, too much "not" like other programming languages and people should refrain from using it.

But people build amazing things with Processing and with Haskell, so I'm probably wrong with my assumptions, haha.

 

Here is what you need to understand with Functional truly means, it's the idea of immutablility enforced over data where the transformations itself are transformable so functions themselves are similar to data and thus everything you create is a composition of those functions itself.

Division of concern to multiple functions with controlled mutability is not what functional describes TBH.

 

It’s not a surprise that FP is getting more popular in UI programming as managing internal state can be cumbersome in OO. It’s much predictable with pure functions and immutability.

Having said that it’s not totally OO’s fault. OO can be rock solid too if it follows a certain standard like avoiding more than 1 level inheritance, program for the interface etc. However the mindset of FP naturally encourages devs to follow good practices like writing smaller and testable units.

 

The direction you seem to be going is towards a Component Based system which would be a derivative of OO but not exactly the same thing.

Languages like Go/Rust are the ones that move towards that direction and seem to be successful doing so.

You might be interested in those.

 

It depends. If I need to do heavy debugging, doing experiments with profiler, and still have people understand the code, imperative is better. If it's for a cheap client who needs another wordpress site where only minor adjustments are to be made - imperative or even just jquery. Is someone is to be working with the code, imperative. If memory is constraint, imperative (c or asm).
As you can see, there are multiple reasons for choosing imperative approach, or at most mixed with js or java8+streams.

 

Agreed with the previous comments that "done" beats formal or elegant. But "done" also means "correct". The mathematical approaches using types/category theory definitely can help with correctness, but set of things you can statically prove about code is mathematically limited. For instance, in Haskell (or any language) the type-checker cannot verify that your definition of a monad satisfies the monad laws. I believe that was the impetus behind QuickCheck for property-based testing.

Property-based testing provides the ability to do "fuzzy" checks of correctness, in the sense that you can't prove a particular property is true for your code, rather increase your confidence as more test-cases are run (obviously if one fails, you know the property is false). This approach is most tractable for pure functions. A property-based testing framework will generate/validate test-cases based on the function definition, which would be much harder if your code under test interacted with the ambient environment in some way, like modifying a global variable.

With Clojure, we've had success keeping the impure stuff at the "edges" of the system, and coding compositions of pure functions to get between impure effects. All those pure functions can be property tested individually, which provides greater confidence that their composition is also correct. The "edge" code is generally pretty simple, taking info from the environment (e.g. database, user input, service request) and passing it to the processing pipeline, and then performing some corresponding effect with the result.

Classic DEV Post from Jun 1

What the heck is a Developer Advocate?

Swarnim Arun profile image
Budding Web Developer, and tech enthusiast with interests and experience in Game and Systems Software Development. FOSS contributor and enthusiast.