Why Functional Programming Matters

Blog Post by: Kaitlyn Khan, Hamza Rashid, Tom Reingold, Tong Chen

In “Why Functional Programming Matters” by John Hughes, the author offers several arguments in favor of functional programming. He claims that functional programs are less error prone than procedural programs and therefore easier to write. He draws an analogy between modular programming and functional programming. Essentially, he suggests that functional programming offers the same advantages and more. (TR) 

The base of functional programming is the use of functions as arguments. The program receives addition, multiplication, other mathematical/programming functions with some elements, lists, and/or even another functional program as part of their argument. Then computes and returns the value. In this case, the function can be viewed as a constant value for the computation. Since it is possible to factor/modify a function without computing all of its value first. Thus allowing the program to compute the value only when it is needed. (TC)

Functional programming also has the added benefit that it has no assignment statements. This means that any computations and modifications within the program will have no effect on other programs and their computations. Which reduces the risk of bugs within the program and allows the programs to be executed out of order. Allowing the user to solve part of the problem at a time when combined with the fact that they can be computed only when it is needed. (TC)

The modular design functional programming, the ability to break problems down and solve them part by part are of great importance when it comes to programming productivity. The small modules can be coded and tested with ease since they often have simple functionalities such as adding two numbers or finding the difference between two numbers. Small modules also have the added benefit of being able to be reused. You might not need the quadratic function for every computation but you will probably need addition, multiplication, and/or division for most of them. (TC)

In functional programing simple functions can be glued together to form more complex ones. For example adding a list is basically adding the first element to the rest of the list. Writing the code in a functional way will allow other functions to be programmed easily as well. Since the small modules are general and allows for reuse. (H.R) 

Page 7 is where he begins introducing map sums which are represented as tree nodes to demonstrate the function flow in his examples. This makes sense considering Hughes’ goal in this article is to demonstrate the superiority of structured programs. Functions can be constantly broken down and represented as their smaller parts onto this tree. Programs, depending on their algorithm may choose to compute simpler functions before moving onto more complex ones. Hughes refers to this as “lazy evaluation”. This is because some functions may occupy too much memory, making it impractical to achieve gluing, this is where functional languages come in. (KK)

Describing the operational steps where function calls wait for different conditions reminded me of what I learned in my previous classes; CSCI 340 to be exact. This class was an examination of various operating system designs, including process management, synchronization, memory and storage management. I remember learning that some processes spend a long time in CPU bursts and make few I/O requests, others compute on different schedules. This order of arrivals can be compared to Hughe’s lazy evaluation. In the process's case, it is usually a predetermined order, such as shortest job first, first come first serve, and priority scheduling to name a few. In Hughes’ examples, he was just explaining how functions can be broken down to process easier, rather than going through the different possible scheduling algorithms that could be used like we were taught in Operating Systems. (KK)

As Hughes’ continued to numerically explain his ideas of functional program advantages, I kept making comparisons like these. A lot of the other prerequisite classes break down sorting algorithms such as these in various ways. Examples could be automata, binary trees, queue and much more. (KK)
            Industrial applications are varied, for example, simulation software. In fact, one could argue that a spreadsheet is a functional program. (TR)

My opinion is that functional programming is limited in use, largely because writing this way is more difficult and therefore time consuming. It seems to me that thinking of the solution as a formula (which describes the data) is more difficult. Donald Knuth advocated writing programs with algorithms that can be proven to be correct. This sounds virtuous but is impractical in most ordinary situations. (TR)

We will implement our radio stream program in a modular way. The program would be broken up into functions rather than being one long code. For example there is a separate play stream function. There is a separate function to load up the 8 streams on the page, and a separate search function. This makes the code more easy to look at and explain as well. If we need to edit or add something we could know what function we have to go to. This way if there is an error with the function we could fix that specific function instead of the whole program. (H.R)