On 10/25/07, Andrew Lentvorski <[EMAIL PROTECTED]> wrote: > 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 do not get this. I see no reason why functions cannot push state (or an entire collection of states) around as easily as they push anything else around ... and obviously deterministically. Thus state has only to be made explict. State(s) become part of the i/o to functions. Not a bad thing IMHO. State does not have to be a side effect. Nor should it be. BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
