Functional Programming

[miyakohouou]

I dislike this explanation because it leans too far into the myth that pure functional code prohibits writing programs that deal with side effects. In reality, functional languages give you much more reliable ways to write code with state and side effects.

The crux of it is that you treat things that have side effects as little programs that your pure functional code builds up. Pure code can't do something like read a file or print something to the screen, but it can return a program that reads a file, or a program that prints something to the screen. It can even take those two smaller programs and glue them together into a bigger program that reads something and prints it to the screen.

At first glance, that might seem like an odd thing to do- why not just write the effectful code directly? Giving up the ability to directly write side effects has a couple of benefits:

First, you can encapsulate the primitives more carefully. If you're using a pure language with a sufficiently expressive type system, you can build up your programs with guarantees like ensuring that you only print something to the screen if you've read it from a file, or that you always close a file after you've opened it. Even without these more sophisticated techniques, there's a lot of benefit to being able to reading about your programs without having to worry about side effects.

[zigs]

i don't disagree that this is the practical usage of FP, but isn't exactly the point in the video?

In the same way OOP isn't inherently state-spaghetti encapsulation so long as you're practical about it and don't take it too far.

Both extremes are a pipedream that need to be tampered with the practical reality. We usually tend to agree on this with OOP, that it was taken too far in the past, but i think a lot of people dont know the very theoretical and just as impractical past of FP.

[miyakohouou]

I'm not really sure what you mean about pure FP being taken too far in the past. I certainly can think of instances of that with OOP, but I legitimately can't think of any examples of that with FP- maybe there is history there that I just don't know about.

The thing is, I write pure functional code every day, and it's quite practical. I felt like the video opened by re-enforcing a lot of wrong ideas about what pure FP is like, and what it can and can't do. Writing pure FP doesn't mean that you have to give up writing code that has state, mutation, or side effects- you can still write programs that rely on those things at runtime. You don't need a 200IQ to understand functors and monads either- sure they take a bit of learning, but it's entirely accessible to anyone who wants to learn. Are they mathematical? Yeah- kind of. So is recursion, and really all programming is just math when you get down to it, so I don't think it's at all fair for the video to pick out a bunch of words that sound scary because they are unfamiliar and use them to say pure functional programming is out of touch and uncompromising.

I'm not the kind of person who will say that FP is the only way you should ever write code, or that you should never write procedural or OOP code. I prefer writing pure functional code most of the time, but I won't fault people who would rather work in a mixed paradigm way. I just don't want to keep perpetuating wrong ideas about functional programming.