I write code, front-end and back-end, and like deploying it on AWS. Software Developer for 20 years, and still love it. Amateur Powerlifter & Parkourist.
Yup. Once you get into Effects/Promises (or Python's awaitables), you start getting into what's really pure.
I call the function, I get back an awaitable, every time. Soo... it's pure.
... but, each of those effects is eager, and runs... so...it's not pure?
So if I start using the Effect pattern instead of Dependency Injection, and defer all actual awaitables from running, then I just get functions back. So...that's pure... until I run it.
At some point, you have to make a call:
I'm using DI, and will inject my dependencies, specifically the ones that actually do the side effects
I'm using the Effect pattern, and will defer all actual side effects until I call a run method
90% of my code is pure, and the side effects are handled at some root level where we know the impurity badness exists
... otherwise, you'll have to either use a different programming language, or build a managed effect system like Elm has.
So as soon as you have IO you will not get "purity" on a higher level.
I just found it a it a bit weird to explain functional concepts on an IO based example and readers who read about this the first time could be mislead about the concept of pure functions. The whole monads machinery in Haskell is to separate actions and pure functions and IO is the standard example for "non pure" actions which can not be expresses as pure functions.
I write code, front-end and back-end, and like deploying it on AWS. Software Developer for 20 years, and still love it. Amateur Powerlifter & Parkourist.
Yeah, agree. The challenges I have with teaching Functional Programming:
many don't use it
many don't know it's a different "thing"
many are forced to use non-functional languages
most non-FP languages have no good way to handle side effects in a pure way
using FP could still help them in non-FP languages
That last point is what I'm trying to help people with. They don't need to be 100% pure to glean benefits of code that is more deterministic.
Even using the pain of Dependency Injection still massively benefits unit testing by removing their need of mocks. Stubs are big, no doubt, but Mocks are larger and harder to reason about.
Completely removing Exceptions allows all their functions to break more predictably in a very imperative way. Some people coding, or learning, still think and code in this way. Go's way of error handling is exactly this. We can give people the Algebraic Data Types of Result and Maybe, allow them to use those FP concepts, yet they still use them in an imperative way. So they don't have to change much about their style, yet they reap benefits.
Even something as simple as using PyDash over Python's native loops has huge determinism benefits.
Until managed effects like Elm has get ported to things like Python/Ruby/Lua, et. all, you basically have the same 3 choices:
give up and learn a pure FP language
use the Effect pattern
use DI
There IS hope, too, as I've seen some Effect style patterns implemented in JavaScript to make things like Promises (wanna be Monads) easier to use and not eager. People aren't going to leave Python. It's our job as FP lovers to help bring the awesome, and "make it work" in their world. I get being pragmatic technically breaks all the math... but I feel it's worth it.
Yup. Once you get into Effects/Promises (or Python's awaitables), you start getting into what's really pure.
I call the function, I get back an awaitable, every time. Soo... it's pure.
... but, each of those effects is eager, and runs... so...it's not pure?
So if I start using the Effect pattern instead of Dependency Injection, and defer all actual awaitables from running, then I just get functions back. So...that's pure... until I run it.
At some point, you have to make a call:
... otherwise, you'll have to either use a different programming language, or build a managed effect system like Elm has.
So as soon as you have IO you will not get "purity" on a higher level.
I just found it a it a bit weird to explain functional concepts on an IO based example and readers who read about this the first time could be mislead about the concept of pure functions. The whole monads machinery in Haskell is to separate actions and pure functions and IO is the standard example for "non pure" actions which can not be expresses as pure functions.
Yeah, agree. The challenges I have with teaching Functional Programming:
That last point is what I'm trying to help people with. They don't need to be 100% pure to glean benefits of code that is more deterministic.
Even using the pain of Dependency Injection still massively benefits unit testing by removing their need of mocks. Stubs are big, no doubt, but Mocks are larger and harder to reason about.
Completely removing Exceptions allows all their functions to break more predictably in a very imperative way. Some people coding, or learning, still think and code in this way. Go's way of error handling is exactly this. We can give people the Algebraic Data Types of Result and Maybe, allow them to use those FP concepts, yet they still use them in an imperative way. So they don't have to change much about their style, yet they reap benefits.
Even something as simple as using PyDash over Python's native loops has huge determinism benefits.
Until managed effects like Elm has get ported to things like Python/Ruby/Lua, et. all, you basically have the same 3 choices:
There IS hope, too, as I've seen some Effect style patterns implemented in JavaScript to make things like Promises (wanna be Monads) easier to use and not eager. People aren't going to leave Python. It's our job as FP lovers to help bring the awesome, and "make it work" in their world. I get being pragmatic technically breaks all the math... but I feel it's worth it.
Hi, good point. What about summarising this as an extra paragraph, and also comment that the way you use "pure" might not be the exact definition?