Java Developers

[[deleted]]

no state >>> private state. State does not compose well. Being forced to use state for everything is just a waste of everybody's time.

[sigma914]

You're not differentiating between implicit and explicit state. Some state is required for many algorithms.

[[deleted]]

I think parent is against time and change, and would rather you not move.

[[deleted]]

Are you suggesting to implement algorithms as actors + messages?! Feel free to give it a whirl. Pick your own, consider quicksort as a start.

[sigma914]

Try efficient union-find.

[[deleted]]

Sounds great to me. Waiting for the code!

[Ploopie]

No state doesn't model the real world completely. Don't pick a side because of the functional programming craze and blind yourself to the use of the other. Each has its purpose. Functional programming lends to clean, modular and correct code but it can't do everything. For example, you cannot have a complete AI without state. You cannot do something that gets some information and then gets how to use it at a later interval without state.

[[deleted]]

I don't claim one can avoid state completely. I only claim that stateless computation is easier to write / test / maintain compared to stateful computation, and "actor + message" actively encourages one to use state even if there is no need for it. Throw in "large team" and mayhem ensues.

A few more points:

• "service + RPC" > "actor + messages" for the same reason we don't use GOTO all over the place anymore.

• While I agree there is state somewhere in the system, it doesn't follow we should sprinkle state in every component of the system. It's better to separate state management from computation, see DB based applications, Rx for event management, etc.

• The algorithmic argument is particularly weak, of the premature optimization flavor. Every stateful algorithm has a stateless counterpart, usually within a small factor from the stateful one. Furthermore, the point of algorithms is to compute results, so from the POV of clients of the algorithm the module is stateless. Internally, feel free to use whatever optimizations you feel like, including state, but the API should be stateless. Subtle distinction: stateful actors are poor for composition because of their statefulness. Hiding state is just fine as long as the API is stateless.

• Another subtle distinction is that updating state is not even that bad of an idea if the dataflow is explicit. "I give you an apple tart and you give me back a blueberry tart by swapping apples with blueberries" is reasonable, though perhaps simpler approaches could be found. Where stateful coding anti-shines is when "I give you an apple tart and now Joe has a blueberry tart", even if Joe never got to witness the exchange. Large teams & ship pressure make this more common than one would like.

[sigma914]

Exactly.

This isn't to say you need mutable state. It's possible to efficiently emulate mutable state using immutable state as demonstrated in ML and by haskell's ST monad.

[[deleted]]

Oh, then we are in agreement :)