DEV Community

Discussion on: Does functional programming have any advantage in real environments?

Collapse
 
quoll profile image
Paula Gearon

Others have pointed out: FP controls complexity. This leads to the ability to develop faster, with fewer people, and greater reliability.

As an example, I was on a team of about 8 devs, building a database in Java over several years. It was released as open source, and I maintained it for several more years. It was about 100k lines of code.

In recent years, I wanted to explore some more ideas, and implemented another, similar database using Clojure. This time, I was on*my*own, and did much of it in my spare time. The end result is about 7k lines. It’s been deployed in products with over 120k installations, and it works. I’m not the only one who’s done this either.

As for availability of developers, FP is so much more fun to use, there tends to be a sense of evangelism around the languages that provide it. Developers are also enthusiastic about getting more people to use their language, since the more it’s in use, the more likely they are to find a job using it. There are lots of resources for learning these language, and many people happy to teach it.

Clojure used to be very niche, but it really has expanded. It’s used by Cisco, Walmart, Target, several major banks (Capital One, Citi, Deutsche), and many more. NuBank relies on it so heavily that they bought the company that supports core development of the language. So there are many developers using it, and many companies in the real world relying on it.

Collapse
 
mojo2012 profile image
Matti

Are the two DBs comparable feature-wise? Would you have been able to develop your DB before the old one with the same outcome?
Can someone else understand your code as well?
You can write super tiny code in an OO language too, but noone would be able to decipher it. (I once got a project like that ...)
I've seen small functional codebases. They were smaller because like in a typical java project you have 1000s of lines of code defining DTOs, entites etc. Guess what, the functional projects just didn't have that. It was all some generic form of lists and objects being passed around - pure guessing, no proper autocomplete etc.
I hated it. It felt so unproductive.

Collapse
 
quoll profile image
Paula Gearon

In order:

  • Yes. The older one has some data import functionality that the new one doesn't have, but this is a very small area of the code base. Most of that functionality was provided by 3rd party tools.
  • No. It was my years of experience that got me to where I am. I would not have even thought that I could attempt such a thing on my own if I didn't have that experience. On the other hand, it was only a FP language that gave me the confidence to try. OO would either lead to state complexity. Alternatively, if I took an FP approach in an OO language, it would come with performance concerns with functional structures that aren't implemented as well, and a constant battle with language idioms and syntax that was not designed for FP (I've done this with some success, but it's pushing uphill)
  • The new code is significantly easier to follow, and several people have. It took 3 weeks of training to do a handover of the previous database code (I did one of those weeks, and 2 other colleagues did the other 2 weeks)
  • You can try to compress your code in any language. I could have done that in FP too, but clarity, maintainability, and extensibility were all primary concerns.
  • The definitions in Java are verbose with little benefit. Scala can offer the same with less boilerplate. Generic lists, maps, etc, offer a lot of power if you have a lot of functions that operate on those few structures (and a good FP language will have this). But you also have the choice of describing structures for compilers in performance critical code. My own DB code has a lot of datatype descriptions, so even when simple things like vectors are passed around, they have to meet conformity constraints. These apply during compilation (so that correct types are passed), and testing, but are removed from runtime code for performance.

I did feel less productive in my earlier days. But this shifted over time. It's the complete inverse for me now, and that's despite having 20 years of OO experience.