Important Update
Fascinating commercial applications of the functional programming paradigm abound today. Why do we hear so little about them? For one thing, functional programming (FP) is not the most common paradigm, and most developers are not intimately familiar with its nuances and applications. We’re going to change that course with a foray into practical FP today!
FP compilers enforce many rules which are foreign to most OOP imperative developers today. The use of recursion instead of ordinary loops, for example, requires a conceptual shift. However, once the logic of a recursive function is resolved, the result is highly reliable and easily readable. Parallelism (or concurrency) is another primary focus of FP languages.
Parallelism is at the heart of today’s increasing interest in functional programming. Erlang is one functional programming language, for example, which uses the actor concurrency model to resolve issues in parallel processing. In this ByteScout feature, we’ll explore several functional programming platforms and their real-world commercial successes.
Our plan for this exploration is to look first at several commercial success stories of FP. This will motivate our survey of the leading FP languages like Erlang, Haskell, and ML. C# pure functions definitely deserve mention here. We will compare code samples and discover the differences between FP languages and more common object-oriented languages. Finally, we will study one compelling FP success story in depth.
Many of the success stories arising from the pure functional programming paradigm are subtle and operate reliably in the background for years without notice. Expert systems operating at the core of our cellular telecom switching networks are highly robust and reliable FP based algorithms. Surprisingly, these are sophisticated low-level device controllers that you might expect to be written in C or Java. In fact, FP apps appear in diverse fields such as:
In fact, there are so many successful commercial and industrial apps deriving from the FP paradigm, that we can only cover a relatively small handful of the most intriguing among them. Hold on to your hat…
Our first functional programming language success story begins with the Promethean Swedish telecom giant, Ericsson. One of the largest global manufacturers of telecommunications equipment, Ericsson operates in 100+ countries with 80,000+ employees. A group of developers at Ericsson Computer Science Laboratory created Erlang as a proprietary language for use in telecom switching and network hardware.
Ericsson uses the Erlang FP language in a variety of telecommunications and networking devices. Applications developed for this equipment prove highly reliable with only a few seconds of downtime over the course for many years. Large-scale, concurrent, real-time applications on devices like the AXD301 ATM switching system achieved an incredibly high level of reliability, as mentioned in this quote by Armstrong:
“The AXD301 has achieved a NINE nines reliability (yes, you read that right, 99.9999999%). Let’s put this in context: 5 nines is reckoned to be good (5.2 minutes of downtime/year). 7 nines almost unachievable … but we did 9. Why is this? No shared state, plus a sophisticated error recovery model.”
Joe Armstrong, one of the architects of the Erlang functional programming language, is also the author of “Programming Erlang, Software for a Concurrent World.” This seminal text from the inventor of Erlang himself is readily available for download in PDF. Armstrong is an advocate of pure functions and immutable data structures, as we’ll soon see in our Erlang intro.
Other popular telecom equipment sold globally includes the DWOS, A910, and ANx. Erlang was originally created for programming these complex and reliable phone network switches. These firmware apps include thousands of lines of code, an awesome demonstration of Erlang’s capability and performance. Erlang is now open source and available at the Erlang home page.
Perhaps surprisingly, financial contract analysis turns out to be fertile ground for functional programming! Formal semantics in contract valuation derives substantial insight from FP languages. LexiFi developed a programming platform to do just this, and it’s based on a combinator API library architected by Jean-Marc Eber and Simon Peyton Jones. The platform is based on the MLFi language and includes UI and dev tools for financial apps.
The primary product of LexiFi tools and applications is to construct and precisely define financial contracts. Contract valuation is implemented through a rule-based expert system and a compositional and denotational semantics system. LexiFi generates C source code from contract specifications. The LexiFi platform also supports operational semantics which specifies contract management methodology as a time function. The LexFi platform is noteworthy for reducing errors in contract resolution.
The functional programming paradigm was cited as the foundation of this platform in an award-winning paper at the Montreal PLI conference in 2000. And the MLFi platform won the Risk Magazine Software Product of the Year award for 2000. Here we can see long range maturity evolving in FP languages, which have been around for decades!
An exciting area of functional programming application is chip design assistants. The modeling and simulation of ICs is an application in the realm of logic and reasoning assistants and model checkers. Bluespec is a commercial success in this area, developing FPGAs (field-programmable gate array) for example.
According to Bluespec, the inspiration for the development of their chip design assistant platforms derives from the Haskell FP language. Bluespec’s products include synthesis, simulation, and other tools for the two coding languages:
These languages are based on a common semantic model. According to Bluespec, hardware behavior is modeled using Term Rewrite Rules. Inter-module communication is modeled with Rule-based Interface Methods. This is an AI field involving the composition of rules from fragments that span module boundaries.
An important area of the FP paradigm which we will see shortly involves the resolution of parallelism problems such as race conditions. Bluespec uses FP methods to reduce race conditions which are important challenges with non FP languages like RTL.
Bluespec’s implementation of Rules also gives rise to deep reasoning simulations of the functional correctness of a system. The concurrency model implemented by Rules is much more comprehensive abstraction than low-level concurrency models of non FP platforms like Verilog and VHDL.
Bluespec’s BSV language supports a Haskell-like polymorphism and overloading. Another FP paradigm feature we will see later is that BSV also handles modules and interfaces as first-class objects. This enables very complex and powerful recursion. Now that we’re talking FP language concepts, it’s time for our intro to FP programming…
We’ve demonstrated that functional programming manifests itself in a plethora of important practical applications today. Now let’s delve into the actual programming methods and see how they work. We will have a look at three of the most popular FP languages today:
Parallelism and concurrency and are often used interchangeably. That’s not wrong, but there is a useful distinction. Parallelism usually refers to dividing a computational task meaningfully into smaller subtasks which can be done simultaneously, and which return their intermediate results to a final computation. The subtasks in parallelism have a role in a common goal.
Concurrency, on the other hand, could mean that three unrelated processes are happening in the background of an OS, for example. You could have a backup operation, loading a spreadsheet into a UI, and a screen refreshes happening concurrently. Nevertheless, concurrency is the word used most in the FP programming books, so let’s go with the flow. A significant challenge in coding parallelism in shared memory allocation.
Here are some of the important differences between functional and OOP programming:
Functional Programming Object-Oriented Programming
Immutable data Uses Mutable data
Declarative Model Imperative Model
Stateless Model Stateful Programming Model
Great for Parallel – Concurrency Poor for Parallel
Good for BigData NOT Good for BigData
Functions with No-Side Effects Methods with Side Effects
Functions are first-class Objects are first-class
Recursive function calls Loops, Conditionals
All of the functional languages we’ve discussed have the above qualities in common with some variation. Let’s start with Erlang.
Here are some of the distinguishing features of Erlang:
Erlang is unique in its method of handling concurrency. Parallel tasks are called processes. Processes communicate with each other via messages. They never share resources. The result is that a process does not care which computer it’s running on. And as a result, highly distributed parallelism functions most efficiently in Erlang.
Javascript recursive functions are possible, but not commonly used. Although one of the hallmark features of FP languages is the use of simple recursive function examples for flow control and the absence of “if” style conditionals, you will notice that the use of “when” in the calculation of factorials in this Erlang sample code adds a conditional:
-module(math). -export([factorial/1]). factorial(0) -> 1; factorial(X) when X > 0 -> X * factorial(X-1).
Haskell is described as a purely functional FP language. It uses non-strict semantics and enforces strong static typing. Haskell is named after the famous logician Haskell Curry. Haskell implements a type system that includes inference, as well as lazy evaluation. The primary compiler in use today is the Glasgow Haskell Compiler.
Haskell is based on Miranda language semantics, but not on its syntax. Here is a great little app that creates a Gregorian style calendar. You can change the numbers to make it work for any year. This is a super demo of the Haskell language syntax:
data DaysOfWeek
= Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday
deriving (Eq, Enum, Bounded)
data Months
= January | February | March | April | May | June
| July | August | September | October | November | December
deriving (Enum, Bounded, Show)
next :: (Eq a, Enum a, Bounded a) => a -> a
next x | x == maxBound = minBound
| otherwise = succ x
pad :: Int -> String
pad day = case show day of
[c] -> [' ', c]
cs -> cs
month :: Months -> DaysOfWeek -> Int -> String
month m startDay maxDay = show m ++ " 2015\n" ++ week ++ spaces Sunday
where
week = "Su Mo Tu We Th Fr Sa\n"
spaces currDay | startDay == currDay = days startDay 1
| otherwise = " " ++ spaces (next currDay)
days Sunday n | n > maxDay = "\n"
days _ n | n > maxDay = "\n\n"
days Saturday n = pad n ++ "\n" ++ days Sunday (succ n)
days day n = pad n ++ " " ++ days (next day) (succ n)
year = month January Thursday 31
++ month February Sunday 28
++ month March Sunday 31
++ month April Wednesday 30
++ month May Friday 31
++ month June Monday 30
++ month July Wednesday 31
++ month August Saturday 31
++ month September Tuesday 30
++ month October Thursday 31
++ month November Sunday 30
++ month December Tuesday 31
main = putStr year
The output should look like this:
Clojure is the dynamic FP dialect of standard Lisp which runs on the Java platform. Like other dialects of Lisp, Clojure code is stored and treated as data and it also features a Lisp macro system. Clojure enforces immutable data structures and dynamic type systems. Clojure likewise supports explicit state and identity management. Clojure is ideal for concurrency apps.
Here is an example of immutable data structures in Clojure:
(let [my-vector [1 2 3 4]
my-map {:freddy "ethel"}
my-list (list 4 3 2 1)]
(list
(conj my-vector 5)
(assoc my-map :rick "lucy")
(conj my-list 5)
;the originals are intact
my-vector
my-map
my-list))
-> ([1 2 3 4 5] {:rick "lucy", :freddy "ethel"} (5 4 3 2 1) [1 2 3 4] {:freddy "ethel"} (4 3 2 1))
That’s a whirlwind sample of FP language syntax. Now let’s look at our feature commercial success of functional programming…
For our feature commercial success in the FP world, we are going to illuminate an ITOM giant that has lurked around the telecom shadows for years. Successfully assisting operators remediate network errors and reduce downtime.
A telecommunication network’s node failure events are generated automatically. As you can imagine, thousands of nodes creating simultaneous alarms can suddenly overwhelm console operators. Needed is an automated system that can parse the swarm incoming messages, and identify a pattern that they are all originating from the same failure event. Ideally, the expert system can intercept all these messages and convert them into one meaningful message to a human operator.
Such a system must contain significant AI characteristics. And as a matter of fact, this system already exists in the form of Hewlett-Packard “Operation Manager i.” The system has been online for many years. Although, HP has changed the name many times, and it is not exactly a household word. The most recent incarnation is called, “HPE Operations Bridge Suite,” and the app is used to monitor a broad array of network events, reaching far beyond telecom.
As mentioned, some network failures generate large numbers of messages. This is called an event storm. The FP based correlator app translates huge sets of events into a single event and sends a coherent message to an operator for remediation. HPE Operations Bridge Suite performs this function with highly reliable accuracy and precision.
The correlator is an expert system, trained by the expertise of the operator to correctly extract the cause of the event storm. This function utilizes the unique pattern recognition capabilities of the FP paradigm languages. The HP correlator algorithm is effectively a network of processing nodes called a correlation circuit.
The ultimate effect is that the HPE Operations Bridge Suite creates a simulated model representing all configured aspects of the network to be monitored. When any configured component fails, the HPE Operations Bridge Suite detects the event and prepares a protocol for alerting a human operator. This system is highly valuable in the management and uptime of networks.
We have discovered that many of the specialized expert systems we rely on every day have functional programming at the core. A significant chunk of the Cloud is monitored and maintained by applications coded with FP concepts that enforce immutable data, flow control via recursion, and stateless operations. These are backbone concepts that visionary architects realized back in the 1950s were necessary to guarantee absolute uptime in systems that we cannot live without! Here at ByteScout, we’re keeping an eye on the important stuff so we can keep you informed!
About the Author
ByteScout Team of Writers
ByteScout has a team of professional writers proficient in different technical topics. We select the best writers to cover interesting and trending topics for our readers. We love developers and we hope our articles help you learn about programming and programmers.
Discover how you can work legally in the USA so that you can grow your career or business. As a freelancer in the USA, you...
Short Answer: Yes, you can use iTextSharp 4.1.6 (please read important information about this particular version 4.1.6 below). iTextSharp is the mature and solid PDF...