3 ms·
You can apply some FP notions to any code base: 1. Don't use globals. Zero global variables should be the goal, that way, you avoid "spooky action at a distan
by spc476 4y ago
You can apply some FP notions to any code base:
1. Don't use globals. Zero global variables should be the goal, that way, you avoid "spooky action at a distance" where some code here changes a global that changes the behavior of code over there. A function that avoids global variables is easier to deal with than one that doesn't. If you feel you need to use a global, think about why you need one before adding it. Maybe you can avoid it.
2. Parameters to functions are immutable. That way, you won't have to worry about data changing during a function call. If the parameter can be mutated, can you signal the intent in the function name or signature, so the programmer knows that to expect? Generally, try to avoid changing parameters in a function.
3. Separate I/O from processing. Do input, do your processing, then output. God, I wish the major component I worked on did that (concurrent DB requests)---it would make testing the business logic so much easier as it can be tested independently from the I/O.
Those three things can be done in any language, and just by doing those three things, you can most of the benefit of FP without the mathematical jargon (Monads? How do they work?). There's no need for over-engineered code, and you can be as explicit as you like while keeping the cognitive aspects to a minimum.
- leidenfrost 4y agoCode readability should be the top most priority when writing code. Even more than portability and performance. Anyone can rewrite a piece of good, succinct, clear code. Even if its performance is poor. That cannot be said for clever hacker code that -was- fast until business requirements changed over time and now the guy that used to understand the code is long gone.
- fleddr 4y agoWell done. Your comment shows actual FP best practices and their immediate, significant advantages. And you did so succinctly.
- john_the_writer 4y agoGods I hate the term monads. I've read the wiki at least 20 times in the past year and it sounds like such bloated rubbish. I love your answer.. And I love how you can use it in every language.
- dmitriid 4y agoFunctional Programming Jargon is great at explaining these concepts. Monad: https://github.com/hemanth/functional-programming-jargon#monad https://github.com/hemanth/functional-programming-jargon#mon... Purists will say it's not entirely correct, but we don't care about purism :)
- leidenfrost 4y agoMy totally informal definition of monads is: "a monad is an island of stateful code in a sea of stateless FP code. On top of that we had some ". Someone correct me if I'm wrong.
- light_hue_1 4y agoIt is indeed wrong. For example, the Maybe monad has no state. It sequences operations that can fail. The Error monad aborts the computation and returns an error. Similarly, Min, Max, Product, Sum, Dual don't have an state.
- bspammer 4y agoYou cannot really understand monads just by reading about them. Or I couldn’t, at least. This is a very good article about the problems with monad tutorials: https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti... > “Of course!” Joe thinks. “It’s all so simple now. The key to understanding monads is that they are Like Burritos. If only I had thought of this before!” The problem, of course, is that if Joe HAD thought of this before, it wouldn’t have helped: the week of struggling through details was a necessary and integral part of forming Joe’s Burrito intuition, not a sad consequence of his failure to hit upon the idea sooner. TL;DR There’s no beautiful explanation that will help you understand, you need to get your hands dirty with code.