i was wondering about the benefits of stateless programming, and found someone who shared my question: Advantages of stateless programming?
as i read through the answers though, it made me curious about the converse question. what are the advantages of stateful programming? seems like there's a lot of focus on stateless code recently but i'm wary of trends.
it seems that stateful (i.e. imperative) programming might lend itself to certain scenarios better than stateless (i.e. functional) programming, and i'd like to be better able to recognize which problems can be solved by stateful programming.
If you have methods or functions that are stateless, and only know about what has been passed to them, they are much easier to test. There are no outside factors that have to be handled, set up, or torn down. It is solely dependent on what you tell it in your test.
Stateful means the computer or program keeps track of the state of interaction, usually by setting values in a storage field designated for that purpose. Stateless means there is no record of previous interactions and each interaction request has to be handled based entirely on information that comes with it.
Functional programs are stateless — since data structures are immutable and variables are not used by design, the program state does not change during program execution. This makes it easier to produce code that can run in parallel systems.
In a stateless program, the program doesn't maintain a state. Instead of maintaining a separate state, the data required for the function to execute are passed as inputs (the program should have value semantics) . The invoked function uses these data, processes and sends back the output to the caller.
There are only a few cases where there are non-debatable advantages to a programming model based on mutable, shared state compared to an immutable, stateless programming model. One area where mutability can bring huge advantages is in allowing algorithms to work in-place. The haskell wiki has a great example about implementing quicksort: http://www.haskell.org/haskellwiki/Introduction#When_C_is_better
To summarize it, when you do not allow modifications to the lists memory, you need to create a sorted copy of it. The same is true for almost any other algorithm that modifies some data-structure, e.g. an AVL Tree.
In general, functional programming languages tend to be more memory-intensive than their imperative counterparts. Memory is cheap nowadays, however bandwith is crucial and memory speeds are not increasing proportional to the increase we see in CPU power. It must be noted however, that the execution model of Haskell allows the Compiler to perform some nifty optimizations, also in regard to memory usage and access patterns. To some extent, this can compensate for the theoretical disadvantages.
Legibility is key. I like functional programming (currently I'm on a clojure binge), but state is how the world works. It's no accident that the Object Oriented paradigm is more popular than functional or any other type of programming. OOP and procedural programming are the path of least resistance for new programmers. Most people intuitively understand the idea of an object as something that changes state (it can be moving, or change color, etc.) rather than the Y-combinator that helps with recursion.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With