@markx After reading SICP, it becomes clear that handling state through closures is like the “atomic” approach to state in most lisps, especially Scheme. It’s mostly used to bootstrap all other more complex state systems (like structs and classes). A class is just a lambda that closes over private variables. So don’t be afraid to use closures in most cases. The only issue usually comes when you start having threads, in which case you need more specific systems like boxes and stuff… But most of the time just closing over a variable is enough to keep state.
@jaerme That’s good to know. I was just worried that it was not “functional”, so I should avoid it. Maybe in Racket there’s a way to completely avoid states? I’m trying to keep my mind open.
There’s always a way to avoid states and do only pure stuff, but in the end if you build anything practical in which there’s a human interacting, you have inputs and outputs, therefore states (before your program was launched / after it was launched, something changed). If nothing changes before and after your program was launched, your program can be considered useless (alas completely pure).
You program, to be perfectly pure, must also not display anything to the console, nor write anything into memory…etc
In the end, having pure functions is just about helping the developer reason through a program design, and debug it. There nothing useful about being pure, except making the program more maintainable sometimes.
It’s just personal opinion now, but I feel like being aware of what state is, and understanding where it is needed or not, is already an incredibly seldom skill in the programming industry that the question about whether or not we should program with state is a way too futuristic and far fetched question.
Most programmers just don’t even know what state is (or what the lack of state is).
I like that perspective
What is state?
something that you can watch change over time
@kennethdevel Look under “Program State”: https://en.wikipedia.org/wiki/State_(computer_science)