[giraffe_lady]

A lot of things can be conceptualized as an operation that takes some stuff, and gives back some new stuff, and does absolutely nothing else.

It's like a lot of other strong constraints on complex endeavors. If you run with it you can get surprisingly far, but only by twisting your understanding of how to do things. Whether that's good or not seems highly personal though.

[george_ciobanu]

This is a great explanation. As someone who's a relatively recent convert to FP and am currently writing both imperative and functional code I will test my own depth of knowledge by trying to explain it

1. In traditional (imperative) languages you can have functions that deliberately or accidentally either modify the data they were given or do some other stuff that changes data somewhere else in your program or the computer. Let's take an example of each. Say you have a function that adds two numbers a and b. In imperative languages you could return a+b into b. In other words the sum(a,b) operation would change b. That's not cool in FP: you are (almost never) allowed to change the input you received. This way whenever the function is called with a and b it always returns the sum (otherwise if you call sum(a,b) again you will pass in a modified b).

This makes every function guaranteed to always return the same value for the same arguments. If you accidentally try to change a parameter in your code it will fail.

But you still need to make changes to the world - you do so by chaining these functions and using the output from one as input to the next and so on.

Last but not least, functions that have side effects (e.g. print to the screen) are marked differently and usually their effect is isolated.

[yoloyoloyoloa]

Haha thanks love this explanation!