> From: [EMAIL PROTECTED] >> Gabriel Sechan wrote: >>Completely and totally disagree. State does not cause problems- state is >>usually the *solution* to problems. The problem comes from not encapsulating >>state correctly. > This is another way of saying that state causes problems. ;-)
No, it isn't. This is saying using it incorrectly can cause problems. Using *anything* incorrectly can cause problems. That doesn't invalidate as a tool. >> The fact that functional programming languages make state and side effects >> so difficult to use are one of the reasons they have completely failed. > That's one way to look at it. The other way to look at it is that the > failure of other languages to address the issues of state and side > effects has resulted in programming being so difficult that programs are > laden with bugs and have such difficulty addressing concurrency and > security concerns. :-) 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. >> There's a reason why the most common design in electrical engineering is the >> state machine- its simple, it works well, and it turns hard to impossible >> problems into easily solved ones. > Yes, state machines are great. They make all problems easy, particularly > if you have billions of states with concurrent state transition events, > guarantees about isolation, state distributed across a WAN with > thousands of nodes, etc. It makes it so trivial to fully validate a > system. ;-) Furthermore, it's great that most programs tend to add > additional states that are otherwise unnecessary for solving a problem, > because that NEVER introduces new bugs or synchronization points. ;-) 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. By the way- extra states should never 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. Gabe _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
