Gabriel Sechan wrote:
While I'm sure they exist, the vast majority of bugs and security
issues I've seen don't exist because state exists. They exist
because someone didn't see a corner case, or just made a mistake.
You haven't come close to proving your assumptions there. Please
show some objective proof why tackling the same problem without state
is less buggy than with state. I'd be interested in seeing it- I've
seen plenty of functional boosters make this claim, but none has ever
been willing to show evidence, only examples of badly encapsulated
state breaking things.
And functional programming *also* has state. It's just that functional
programmers generally attack state with *copy-on-write* semantics.
Consequently, there are whole sets of "state sequencing" problems that
just vaporize.
However, that doesn't work very well when creating a copy is expensive
or when there really is just one single "thing" which needs to get
passed around.
See, Okasaki, "Purely Functional Data Structures"
So, functional approaches to state often trade "broken" for "so slow it
might as well be broken".
I didn't mean to imply that they make every problem easy. But they
make many problems simpler. I'd rather deal with synchronization
across thousands of nodes with a state machine than without one.
And they become intractable just as quickly. The EV-6 hardware decode
state machine was fairly simple by software programming standards, and
yet even the smartest minds were at a loss when asked, "How do we make
the critical path faster?"
Cache coherency protocols have very simple state machines, yet they
*always* have bugs.
By the way- extra states should never exist.
Certainly not true. There are many reasons why extra states may exist.
There's proven
algorithms to compress states to the absolute minimal number.
There's also lots of nice tools from the EE realm to validate state
machines that can make verifying designs easier.
And those tools operate in O(n^2) (or worse) time. Even with the
computer power we currently have and nice simple microprocessor state
machines, those tools get bogged down very quickly.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
