[Tutor] Side effect and return value

[dn]

On 20/09/24 08:40, Albert-Jan Roskam wrote:
>     Hi,
>     I've just read "Code that fits into your Brain".
>     The author says a function with a side effect should not have a return
>     value. But how would one write this function in order to do that? This
>     looks totally fine to me:
>     from uuid import UUID
>     from requests import post
>     def create_user(info: dict) -> UUID:
>         resp = post("https://some-thing/user", json=info)
>         resp.raise_for_status()
>         return UUID(resp.json()["id"])

It took me a moment to realise that what I was (trying to) remembering 
is Mark Seemann's book, "Code that fits in your Head".

It does have a chapter with such as its title. However, a quick skim 
didn't readily-reveal discussion of side-effects, etc.


Perplexity.ai saved me some time and typing, offering the following for 
your reading pleasure:

«
Key Characteristics of Functional Programming

1 Pure Functions: A pure function is one where the output is determined 
solely by its input values, without observable side effects. This means 
that calling a pure function with the same arguments will always produce 
the same result, and it does not alter any external state or interact 
with outside systems (e.g., no modifying global variables or performing 
I/O operations).

2 Avoiding Side Effects: Functional programming aims to minimize side 
effects, which are changes in state that occur outside a given 
function's scope. By avoiding side effects, programs become easier to 
understand, test, and debug. This is because functions behave 
predictably and independently of the program's state.

3 Immutability: Data is immutable in functional programming, meaning 
once a data structure is created, it cannot be changed. Instead, new 
data structures are created when modifications are needed. This 
immutability helps prevent unintended side effects.

4 Higher-Order Functions: These are functions that can take other 
functions as arguments or return them as results. This allows for 
greater abstraction and code reuse.

5 Declarative Style: Functional programming focuses on what to solve 
rather than how to solve it, using expressions and declarations instead 
of statements.
»


Sadly, the difference between 'theory' and 'practice' is that it is 
impossible to write an application which contains ONLY "pure functions". 
The example code (above) MUST perform I/O and step outside of the 
application.

So, and particularly in Python, Functional Programming involves 
acceptance and compromise.


The specific question:
«
In functional programming, it's often advised that "a function with a 
side effect should not have a return value." This guideline helps 
maintain clear boundaries between functions that produce values and 
those that perform actions (side effects). By separating these concerns, 
the code becomes more modular and easier to reason about.
»

@Cameron's post illustrates such very neatly.


Accordingly, the 'compromise':

- if the routine is all about a side-effect (the POST and response), 
forget that convention
- if the routine is 'pure', then follow it.

ie it's good advice worth following, but maybe with some 'situational 
adherence'.
- or does "nuanced approach" sound more judicious?

-- 
Regards,
=dn