The functional programming paradigm at enterprise scale

Functional programming basics

A pure function is one that has no state stored around it, making the respective application state immutable. Given the same input, a pure function will always return with the same output. In an object-oriented language, such as Java or C#, the results of the same functional call could be different if the state of the object changes. Even procedural languages like C can generate global variables and make database calls; these changes to the database will also change the output.

The functional approach tends to be declarative rather than imperative: Functions tell the computer what to do, not how to do it. However, this also means that functions don't provide any method of workflow control. A procedural programmer will have to loop through every row in a database, look for the values it wants and then add those values to a separate list. Alternatively, a declarative programmer can simply write a SQL procedure, rather than specify file storage locations or data retrieval processes.

Pros and cons of functional programming in the enterprise

When the open-source Perl community fashioned a five-year plan to implement the Perl 6 compiler, famed programmer Audrey Tang single-handedly wrote a reference implementation in Haskell in her spare time, completing the project in just under a year. This high level of productivity is the great advantage of functional programming.

Of course, not every programmer has Aubrey Tang's skill. Even if a company manages to hire this caliber of programmer, there's no guarantee that person will be around when the codebase goes into maintenance mode. Another downside is that functional programming languages like Lisp, Haskell and F# are not all that popular. In fact, Paul Graham, a programmer and entrepreneur renowned for his work in propelling the use of Lisp, theorized in a 2003 blog post that development team managers lean on popular languages like Java, C and Python because it makes them easily replaceable.

On top of all that, application development products that offer out-of-the-box functionality will likely contain plugins that are based in popular languages, such as Java and Python. This means the baked-in code will revolve around procedural or object-oriented programming. Finally, when it comes time for a company to create new application systems, management will likely be reluctant to take the risk of ditching these development systems in favor of a functional programming paradigm.

Despite these challenges, there are a few ways that a motivated enterprise can successfully embrace functional programming. Let's review a few of these techniques. 

Enterprise-level use cases for functional programming

Things like batch processing, front-end development and procedural language manipulation present some practical use cases for functional programming in the enterprise. On top of that, these use cases also provide good opportunities to incrementally introduce a functional programming paradigm within an existing codebase.

Batch applications that take one set of data and transform it, or extract, transform and load (ETL) are good fits for a purely functional approach. Batch and ETL applications do not rely on stored, mutable state information, such as a list of customer events that impact or demand data. To this end, compilers could be considered a special kind of batch program, and a language like Haskell can introduce a functional approach while keeping track of state using various libraries.

The functional programming paradigm is also useful for front-end development. Modern user interface design approaches often decouple the display of the data to the user from the back-end processes that gather that data. A development team's adoption of functional programming could start with a simple API call method that renders customer data into a webpage view.

Approaches to this type of front-end functional programming are in widespread use today. React, for instance, is a front-end JavaScript library that supports functional programming, even for individual webpages. This same trend touches mobile-app development, as well. For instance, Apple's Swift enables developers to call types as functions, and Flutter's widget tree framework employs a state-management approach that provides the building blocks for functional programming.

Finally, the community of designers working on functional programming languages has also developed ways to embed functional code within classic procedural languages and frameworks like C and Java. LINQ, a data-query extension found in .NET and an embedded "what not how, no state" query language, is one such example. Another example is the java.util.function package, which makes it possible to build declarative code in Java using a functional style.

Getting buy-in for functional programming

The most straightforward way to add functional programming is to embed it into existing code, ideally accompanied by copious documentation and thorough code reviews.

However, introducing a functional library like React will require more buy-in from both the development team and management. Building an entire subsystem based on a functional programming paradigm will take time, likely with delayed results -- a proposition that is always tricky in the enterprise. That said, in cases when a single programmer that experiments with functional programming tools and proves that they can build a new API faster than the existing process allows, there's certainly a chance that they fetch some attention and get permission to move further.

The next logical question, then, is how the enterprise will support the new code over time. Again, that will require buy-in from the team, documentation and support from the architecture group. Without this support, an attempt to pursue functional programming is unlikely to succeed. Try to get those pieces in place as early as possible -- it will be worth it in the long run.