That statement probably made you recoil a bit. You might be thinking "Better is subjective, it's better only in your opinion" but this is not true and I will tell you how. If you are a developer, just by learning Functional Programming, your skills will improve. Even if you primarily use an Object Oriented language (aka OO) and continue to after learning FP, your OO code will improve.
This is because #FP holds incredibly valuable lessons. Within this paradigm are little nuggets of truth that have been lost to many developers over time, and these same little nuggets apply to OO programming as well. Through learning #FP, my own Ruby code improved significantly-- but in order to mine down these golden nuggets of truth, we need to start at the very basics.
In my opinion prototypes are bad, ES6 classes are bad,
this is bad, and all of them lead to worse, more confusing code. I am not a purist, I work with libraries, developers, and codebases that use all of these consistently. And I don't believe others to be bad developers for using them. However, I do believe the systems themselves are bad, and are forcing developers to become lion tamers to their codebase. At their core, they make writing good code harder. For this reason I don't use them in the code I write, and if you are willing to learn how I would love to teach you.
You can't just start quickly writing fully pure and functional code, it needs to be learned, just as you learned OO-- In small pieces and with practice. The good news is that you can easily start, one piece at a time, in your current production code! Let's start with the most basic concept in #FP, constants.
Constants are variables that are... well constant. Meaning that you can not re-assign them. For example you can normally do the following:
var foo = 'bar' foo = 'baz'
This will run fine, however the following will throw an error:
const foo = 'bar' foo = 'baz'
Now why the hell would you want this to throw an error? Because this is a great way to communicate that the variable should not change both to yourself and other developers. Take the following example:
const dbConnection = connect('path/to/db/')
This is a great time to use
const because you likely do not want
dbConnection to ever get changed during execution, whether it be on purpose or accidentally. You already have variables in your JS codebase that should be constant. Using
const to enforce that is reason enough to start using it today.
Now, if you have looked into Functional Programming before this article, you may know where I am going with this. You are probably aware, at some point through this series, I will tell you to strive to make every single variable a constant. This is true, but you don't need to worry about that right now.
All you should worry about today is making the variables you think should be constant, constants. That is easy enough right? In Part Two I will make sure to cover constants in depth, with explanations on how and why you should make every, or at least most, variables be constants.
Follow me on Twitter to know when the next post goes live.