It's a good idea to keep calculation of values (expressions) separate from execution of actions (statements). We want precise control over where and when actions will be taken (like displaying messages), but when calculating values we'd rather work at a more abstract level and not have to care about how those values are being calculated.
A function which only calculates a return value, using only the arguments it's given, is called pure.
A "function" which performs an action is actually a procedure, which has an effect.
Any effects caused during the calculation of a value are called side-effects, and it's better to avoid them where possible ("I just needed that string, I didn't know it would hammer the database!").
To minimise the chance of side-effects, we should avoid sending too much data to our procedures, or putting any calculation in them; if some calculation needs to be performed beforehand, it's usually better to do it separately in a pure function, then pass only the required result to the procedure. This keeps the purpose of the procedure clear, and reduces the chance that it'll be re-used by later as part of a calculation (the pure function can be re-used instead).
For the same reason, we should avoid processing results inside a procedure. It's better to return the result (if any) our our action, and perform any subsequent processing with pure functions.
If we follow these rules, we might end up with a procedure like
sayHello, which doesn't need any data and doesn't have a result. Hence the best interface for it is to have no arguments and not return a value. This is preferable to, for example, calling "console.log" in the middle of some calculation.
To reduce the need for effects during calculation, we can have calculations which return procedures; eg. if we need to decide on an action to take, we can have a pure function choose a procedure and return it, rather than executing it directly.
Likewise, to reduce the need for calculation during procedures, we can have procedures take other procedures as parameters (possibly the result of a function); eg. taking an array of procedures and running one after another.