Even though functional programming has been around for over half a century, it has never gained the kind of popularity anywhere near what imperative programming (e.g. C, Java) achieved. Nevertheless, it seems to have been increasingly talked about in the technology world.
So why is functional programming gaining attention?
For starters, there's the prominence of JavaScript. Not only has JavaScript dominated on the front end of web applications, it has also become a prominent server-side programming language since the emergence of Node.js. An untyped programming language, JavaScript supports first class functions and has undoubtedly helped promote the functional programming style across the frontend and backend tiers. The current trend toward uses of reactive, functional styled libraries such as RxJS and Cycle.js within the JavaScript community certainly helps as well.
There's also an increasing demand for numerical analysis, statistical computing, and machine learning algorithm development. All that involves composition of mathematical operations that favor the functional programming style. For instance, the increasingly popular programming language for statistical computing, R, is at its heart a functional programming language.
What is functional programming?
Before we wander too far off, let's take a step back to briefly refresh our understanding of what essential characteristics functional programming possesses. As the name itself suggests, functional programming resolves computing problems via mathematical functions. In fact, almost everything you might've heard about functional programming correlates to mathematical functions in some way:
Functional programming:
- supports first-class functions -- i.e. supports assigning functions to variables, passing and returning functions as arguments and returned values, respectively, to/from other functions
- is a declarative programming paradigm that emphasizes 'what' rather than 'how' and treats computation as the evaluation of mathematical functions
- avoids mutable state and side effect -- i.e. avoids modifying state outside a function's scope or interacting with its calling functions (except for returning its value to them)
- has its root in Lambda Calculus, a.k.a. λ-calculus, a mathematical logic system that expresses computation based on function abstraction and application using variable binding and substitution
- handles flow control via composition of functions and recursion
An example snippet using functional programming
As an illustration, let's look at some code example. Say, we have this presumably large text file on the Apache Spark distributed platform. For each distinct word in the file, we would like to count all the words following it.
Solving this problem with an imperative programming language would likely involve iterative loops and complex programming logic using mutable variables as counters initialized outside of the scope of the code blocks. On the contrary, a snippet of composable functions in a functional programming language like Scala can be as simple as follows:
// For each distinct word, count all the words following it
val resultRDD = textFile.
flatMap( _.split("""[\s,.;:!?]+""") ).
map( _.toLowerCase ).
sliding(2).
map{ case Array(x, y) => ((x, y), 1) }.
reduceByKey(_ + _)
Through composable operations including words break-down/flattening, a sliding window function for collecting word pairs and a MapReduce operation for word count, the code snippet employs stateless transformation of immutable data and avoid side effects, allowing Spark to parallelize the tasks for large-scale data processing.
Although an imperative programming language might also be able to make use of the handy sliding window function or MapReduce operations like in the above example, the iterative logic flow with mutable states and side effects would make it difficult to do so. In case you aren't aware how much functional programmers despise iterations, take a look at an internet meme of flatMap-that-shit.
So, is functional programming better for startups?
Let's say you're building a startup company as its software technology head, and you're going to start with a clean slate to build a software product. On the core language platform, would you be leaning towards a functional programming language such as Haskell, Scala, or an imperative programming language like Java, Python?
One of the reasons I single out startups for the topic is that the 'luxury' of building something from scratch is evidently more common in young startups than in established companies. Given the predominant popularity of imperative programming, if you inherit a software technology stack and an engineering staff in an established company, chances are that's the paradigm and skillset you're going to get and stick to, as a paradigm shift and skillset change can be both costly and disruptive.
Another reason is that startups, by nature, tend to be a little more fearless in risk taking. Acquiring talent in the functional programming arena can be challenging due to the rarity of software engineers with those skills. Yet it's not unusual for startup CTOs to knowingly adopt a technology stack that presents such risk. In some cases, they even go as far as to take on some technology that isn't entirely within their own skills comfort zone.
Functional programmers versus imperative programmers
In approaching a computing problem at hand, functional programmers generally have a different view when compared with imperative programmers. The former group would try to formulate a solution to the problem as a series of transformations on immutable data in a declarative fashion, whereas the latter group would focus more on building procedural subroutines with changeable state. The latter approach is arguably more prone to issues related to concurrency, distributability and code maintainability -- although some experienced imperative programmers are good at producing code that aligns with the essence of functional programming (i.e. minimizing mutable state, side effect) through self-discipline.
My observation has been that an average functional programmer does generally exhibit better programming skills than an average imperative programer. I believe this has to do with the fact that there is a higher percentage of junior programmers in the imperative programming world than that in the functional programming world. Such phenomenon could stem from a relatively higher barrier to entry as a functional programmer. Similar to the case in the systems/database administration world, you can't claim yourself a functional programmer until you're pretty experienced already.
Other deciding factors
In an early-stage startup, you typically need software engineers to get off the ground from day one, so you generally recruit only the experienced. From that perspective, it does make functional programmers a more attractive target group if you're free to pick a programming paradigm.
Perhaps one of the most deciding factors is the type of software application you're going to build. For instance, if extensive data science work is a requirement, and if the data is of a scale large enough to warrant using of some distributed computing platform for parallel processing, functional programming would probably be a favorite pick.
But then, oftentimes there are more critical factors governing your decision, and one such factor is time to market. Say, you're given a short time window for the deliverables and there are a couple of trusted imperative programming gurus ready to dive in with you. It would probably be wise to suppress your urge to go with your preferred functional programming to leverage your immediately available assets.