Haskell: How a Lazy Language Was Put to Work (Part Two)

Haskell: How a Lazy Language Was Put to Work (Part Two)

Haskell and the rise of functional programming

2000 - 2015

A major pro-Haskell change in culture has been the rise of functional programming (FP). While much of FP’s contemporary popularity has to do with its value to FinTech, it wasn't until the mid-to-late 2010s that FP became (among its other uses) a FinTech solution. To uncover the full story of Haskell’s arrival to the mainstream, this section of the series will focus on the roots of FP’s reputation and how the paradigm first began to spread. To end this section, we’ll discuss Haskell’s early adoption by traditional financial institutions, before engaging with its use by blockchains and cryptocurrencies in the next section. By setting aside FinTech for a moment, then circling back, the route taken by FP toward its current reputation may be more completely understood.

In the early 2000s, after the first multicore processor was released by IBM in 2001, FP was heralded as "the paradigm of choice for unlocking the power of multicore processors," and "suitable to take advantage of the multi-core trend in computing." Because multicore processors were commonly understood as a definitive step forward in computer technology, the advancement garnered huge media attention. The association drawn between multicore processors and FP linked interest in the former to adoption of the latter.

A slew of late-00s developments in web programming picked up mainstream attention at the tail-end of the multicore boom. These changes indirectly uplifted functional programming. 2005, 2006, 2008, and 2009 saw the releases of Ajax, jQuery, Google Chrome (including a JavaScript engine), and Node.js respectively. This meant that by 2010, JavaScript was in position to monopolize web development, as developers could "utilize a single programming language to build a web application." Distributed across the internet by JavaScript's new ubiquity was the seed of something more functional than object-oriented: "Before about 2006, JavaScript was widely considered a toy language used to make cute animations happen in web browsers, but it had some powerful features hidden in it. Namely, [...] lambda calculus."

JavaScript's inclusion of this concept foundational to FP -- so essential that Haskell's logo is based on the Greek letter lambda -- helped to widen the field of possibility for web development. By 2013, developers could assert (whether true at the time or not) that "JavaScript makes functional programming quite straightforward and simple." After 2015's FP-feature-heavy ES6 update, this perception deepened. One could "rewrite common operations available natively in other functional programming languages into JavaScript (with mostly one liner expressions)." JavaScript is in no way singularly responsible for functional programming's present popularity, but its paradigmatic hybridity, especially after the ES6 update, played a role in FP beginning to "infect [the] brain" of a generation of web developers. The impact of JavaScript on Haskell was not all so indirect.

By inefficiently enabling FP as a possibility for backend and frontend development, JavaScript was the common problem a community of Haskellers could coordinate to solve. For example, buried in a 54-comment thread from 2014 on /r/Haskell asking, "What is the state of 'The JavaScript Problem'?" one user’s reply points directly to the longstanding conversation generated by The JavaScript Problem on /r/Haskell: "There are threads about this regularly. Previous." JavaScript's entrenchment acted as a catalyst for a decade of Haskell development, from compilers like Haste, Fay, and GHCJS, to the library Reflex, to the full language PureScript. By 2015, web development had become (and remains) a primary use case for Haskell. It was also possible by then to say that Haskell was used "in high frequency trading," but, because FinTech was still inchoate, that element of Haskell's identity was treated as an outlier among its other qualities and uses.

As big businesses' data processing needs scaled beyond what their object-oriented architecture was designed to sustain, they sought alternative paradigms. In 2008, in a very early implementation of FP, Barclays developed their Functional Payout Framework in Haskell and published a white paper on the project. This legitimized Haskell's viability at the scale of a global financial institution. Later, in 2015, Facebook rebuilt its spam system Sigma in Haskell, adding more credibility to Haskell's reputation for handling large-scale data processing. Though Barclays and Facebook employed Haskell differently, they justified their usage similarly. It was due in part to Haskell's intrinsic technical qualities -- those features that differentiate it from common (mixed-paradigm) alternatives like F# and OCaml -- and in part to its reputation as the leading functional programming language.

From 2008 to 2015, by accumulating use cases in production, Haskell established a real-world financial value for itself that began to stand apart from its scholarly and scientific value. In the next part of this series, we'll discuss how changes in the late-2010s and early-2020s continued this trend; specifically, how the invention of blockchain technology accelerated businesses’ experimentation with Haskell as a FinTech solution into real-world use in critical systems. After that, we'll discuss the Haskell community itself more closely — how its members preserve essential elements of Haskell, and how they let some of its components change. Before blockchain, traditional FinTech had been courting Haskell; since 2015, contemporary FinTech has been in a complex relationship with the language, and Haskellers have made their range of opinions known.