Beginners Guide to Functional Programming: Part 1
Beginners Guide to Functional Programming: Part 1
An awesome introduction to functional programming that's in-depth and easy to follow. Read this article first before you voyage into Scala programming.
Join the DZone community and get the full member experience.Join For Free
The CMS developers love. Open Source, API-first and Enterprise-grade. Try BloomReach CMS for free.
Steven Sacks, a friend of mine, and I have been learning Functional Programming over the past year. We’ve both cut our teeth on finding who to learn from, what articles are useful, and what actually translates into your day to day programming job. I’ve also learned a lot of natural problems that arise as you start a new project from scratch with an OOP background, or if you’re refactoring some OOP code to be more functional.
Why Even Bother?
Here’s my list derived AFTER actually doing it vs. rehashing marketing I’ve read elsewhere.
- Code works more than it doesn’t.
- Unit tests are easier to write.
- Unit tests break faster allowing me to fix broken code they found faster.
- Easier to figure out what the hell is going on in a larger code base. If something breaks, it’s easier to pull things apart and improve the testing of those parts to prevent it from happening again. Not like usual spaghetti that can occur with mutable state.
- Don’t get bit (as much) by concurrency/parallelism bugs that can arise in server or testing environments.
I’ll elucidate more on those topics below.
I can tell you from consulting experience and my new job that OOP, mutable state, and languages that support them are alive and well.
Time and Cognitive Load
The other two reasons are it takes longer to make things mathematically correct, and as you learn, you often refactor functions a lot to make them more pure. While that’s great, you bubble up the variables storage and creation to a higher level. Over time this results in you eventually having to store and get that data from somewhere. Frameworks like Redux help here, but it takes more time to make things nice and pure. While the cognitive load (keeping how the program works in your head as you read the code) actually lowers with pure functions, assembling and testing them can take a lot out of you once you start dealing with higher order functions and work out how to test the larger functions. This is assuming you’re doing tests in tandem with your code.
The Good News
Typically I start these articles with the bad news first, but given the scope of the endeavor we’re about to embark upon, I felt it necessary to start positively.
You most likely already know a lot of this already.
Additionally, there is less overhead in applying these techniques into existing code bases. You can pull in functional techniques (and you probably already have) while still staying true to an existing code base’s OOP bent, nor with adversely affecting anything. Some are language agnostic.
This stuff is easier to grok than a lot of these academics and 300 IQ programmers make it out to be. I’m an art student learning it with good old hard work, which means so can you. Like anything, it just takes practice.
The Bad News
You’ll have to wade through a lot of Google search results to find blog posts, even StackOverflow answers, written in English. A good many, well meaning academics write these posts using proper terminology, but you leave not knowing how any of it relates to your day to day job and how these techniques can help your daily problems. Smart programmers have taken it upon themselves to give code examples that help you understand how to write functional code, but you’d never actually need a function that adds 1 to 10o in the real world.
If you grew up in OOP like me, it’s hard to break a decade or more of habits you’ve engrained in your brain. Worse, you’ll have patterns and ways of thinking that shape how you approach solving programming problems.
The industry as a whole, at least for web front end (and some Node) is built around mutability and state. Reading text files, databases, encapsulation with classes, and other state full things have copious tutorials and StackOverflow answers with state. Because it’s easy. Because it’s quick. Because it works.
Simplification of many terms also poses a challenge because some people think you either cheapen it by doing so, incorrectly explain it by not using all the appropriate terms, or are flat out wrong by pointing out the core value. Ignore it, there are diamonds inside, you just have to ignore all the yuck that goes with mining. Think Minecraft: no grime, just your time.
Beware Professors and the Elite
It’s worth re-iterating: beware academics and elitists. Functional Programming can be for the masses, not some secret cult. Additionally, you can use pieces and get the benefit; you do not need to go full bore to realize positive results in your code and day job.
Try it in pieces. You won’t hurt yourself, nor destroy your codebase. If you offend some PHD, oh well, the world goes on.
Is This for Apps or for Games or Both?
I’ve done no active research for functional programming in games, but did see that Elm Repeatable Mario demo. Using the Component Entity System model, I’ve been having fun trying make a mash up of Final Fantasy 6 and Final Fantasy All The Bravest.
Stay tuned for part 2, where we'll go over a glossary of terms and get into some code examples.
Published at DZone with permission of Jesse Warden , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.