Since the dawn of the computers, us software developers have been in pursuit of the holy grail of computer programming. We have long sought after the achievement of writing code in a way that is elegant and beautiful in design. Code that inspires tears from our peers who can appreciate the beauty of how you painstakingly woven together such a beautiful piece of art. In fact, at the beginning of each new software development project, as any developer will tell you, it is another opportunity not to screw up the code for this one. We all start off with a statement like “this time…this code will be the most elegant code ever written!” Going into each project with this state of mind, we are often let down by how awful our code turns out as we are thrown challenges like time/budget constraints and missed features. Often, we create tech depts and @todos to go back and fix our shortcomings in code. But never return as there is no time or money to do so.
The Functional Programming Paradigm
In our pursuit for unmatched elegance, we invent new ways organizing code. Throughout the history of software development, we have invented several ways of code organization and identify them by name. Each new way we invent is known as a paradigm. As each paradigm is a new way of thinking about how we can orchestrate code to make it more elegant. One of the latest paradigms to pop up on the radar of many software developers is a paradigm known as functional programming.
History and Purpose of Functional Programming
Functional programming goes back to the beginning of software development as it was created around 1960 as a part of the LISP programming language. It was designed to maintain the same principles as a function in mathematics. Like a function in mathematics, functional programming functions follow that the they represent relationships between a set of inputs and the outputs they generate. In other words outputs of functions are predictable based on their inputs. No outside states, models, or data can manipulate its output.
In the most prevalent software development paradigm, known as object oriented programming, the idea of state, model, or data differs in functions as the output of functions are traditionally very heavily influenced by state, model, or data and not just its inputs. Functions in object oriented language are designed to contain some logic to check external states as this approach makes reusable code easier to apply. Functional programming removes the ability to easily share code because the state, model, or data a function depends on has to become a input of the function. You will ultimately find yourself cutting and pasting many code snippets as you will find multiple functions will require the same logic.
Where Functional Programming Fits
The buzz around functional programming comes from the peak in interest of artificial intelligence research. Many people are developing an interest in artificial intelligence and are looking for a way to start programming on this new platform. The software development paradigm that makes most sense for artificial intelligence is functional programming. At this point, many start developers are seeing the benefits of functional programming in artificial intelligence and are trying to apply those same principles to business user applications. Many publications have surfaced around the idea that functional programming will start finding its way into other segments of software development. Trying to apply functional programming principles to end user application architecture will not be a thing. There are many developers pushing for this, but in the end, object oriented programming makes much more sense for the end user applications we are building today. Again, this is another sign of the fact that we are in search for the holy grail of elegant design in code.
The post Functional Programming Not The Next Software Programming Paradigm appeared first on UA1 Labs.
Top comments (3)
The only thing about this article I can agree with is the sentiment that functional programming is not the silver bullet paradigm. When it comes to the lowest level and highest performing code, imperative styles have an edge. (And by the way, it so happens that there exist hybrid languages which do both FP and OO, like F#.)
All the other assertions and implications of this article are hilarious. FP is only for AI research? Nope. "FP removes the ability to easily share code"? Nope. "Trying to apply functional programming principles to end user application architecture will not be a thing." (This made me laugh.) Have you seen Elm?
I urge you to give FP an honest try before guessing at reasons not to like it.
I never said I didn't like it. I prefer it, in fact, it makes unit testing a breeze!
I never implied that functional programming was for only AI.
And yes when you restrict sharing state within functions, you reuse logic. Essentially using the cut/paste design pattern ;).
However, as we both agreed, it is not the end all be all paradigm we should flock to for all of our programming needs.
What you are saying does not sound like any functional programming I know. I use FP for everything I can except for performance/efficiency critical sections. Because it makes testing, reuse, and maintenance easy.
Edit: It sounds like you are trying to apply OO principles like information hiding in your FP code. This is probably why it seems so copy-paste heavy to you. It also sounds like you are primarily criticizing Lisp. While this is certainly a capable FP language, there are many others with different (very practical) emphases. Check out this video and also this site to learn from someone who professes to write BLOBAs (Boring Line-Of-Business Applications) using FP.