advantages of stateful programming? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

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.

Answer 1

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.

Answer 2

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.

Answer 3

State is important. Every bit in this universe have state, it is the state that defines how a system behave, the state makes the system dynamic and usable, but as state is so important it is also important that how this state is accessed and manipulated. It would not be good if any human can manipulate the state of other human (state as an the content in the brain of a human). My view on state is that it should be made explicit and should not be something that is scattered across your code and become very implicit that it is hard to know what state the system is in and which part of the system is responsible for which part of the state. State should be controlled in such a way that you can easily say that this part of the state of the system is handled by this module and only this module.

In any real world FP program it will always have 2 parts, one which is stateless that would be you core algorithm etc and other part which will maintain the state of the program.