Sometimes we want to write functions that have side effects. Subshell functions don't have side effects. Sometimes you don't want side effects, but sometimes you do, and it's silly to completely foreclose on even the possibility of using side effects.

The article didn't say you should always use subshells for functions, no exceptions. Just that most of the time it probably makes more sense to do so. And subshell functions can still have side effects like interacting with the filesystem, they just can't modify the parent shell's environment.

Isn't grep your friend in this situation? I'm really not sure why you can't have side effects in this scenario.

A “side-effect” in this case is the ability for a function you call to do something “outside” of itself. For example, to change the value of a global variable.

It’s generally considered best practice (in the functional programming community at least) to write “pure” functions (that is, functions without side effects) because it’s much easier to reason about what they are doing.

So good news, subshells can _only_ be pure (the only way to get anything back from them is if they write some string to stdout), but sometimes you do actually want to have some side-effects (imagine a function that reads a config file and then wants to set some of the global variables to the values found there).

Well, bad luck. If you use the subshell syntax you literally can’t do that.

What on earth does grep have to do with side effects?

And what makes you think side effects aren't possible in the model described?

Think of grep as a way to control flow. If one side effect happens, send to stdout one thing. Another side effect, send something else. Then iterate over those outputs.