3 ms·

Yes. You can model state easily in functional programming languages but the technique is unfamiliar to imperative programmers since it's more explicit. This i

by nilved 10y ago

Yes. You can model state easily in functional programming languages but the technique is unfamiliar to imperative programmers since it's more explicit. This is a very good thing.

darksaints 10y ago
More explicit? Try more convoluted. Ever try to build an event-driven FSM in Haskell? I've seen several try, including myself...the results of which have all been complexity disasters. Imperative languages in general have poor data structures for representing state (no ADTs!), but nothing is more explicit and straightforward than using mutable data or mutable containers for modeling actual mutable state. That's why languages like Scala exist. Functional without religious paradigm enforcement.
- nickpsecurity 10y ago
  I don't do FP or Haskell but did do FSM's in imperative languages. Looking up Haskell's event-driven FSM's... https://wiki.haskell.org/Real_World_Applications/Event_Driven_Applications https://wiki.haskell.org/Real_World_Applications/Event_Drive... https://accu.org/index.php/journals/2199 https://accu.org/index.php/journals/2199 ...gives me code that looks weird since I did imperative but straight-forward. The second link even shows some simplicity and less tangling vs imperative examples. I wonder what makes you think FSM's in Haskell turn into disasters if these examples were so easy. Besides, you shouldn't be hand-coding FSM's to begin with. The various sub-fields of programming and IT I've studied all came from different directions to same best practice for FSM's: DSL's that generate them. LISP people did it forever. iMatix did it for reliable, distributed apps in C. Haskell embeddings go from stuff like that up to hard real-time C. Theres also open-source projects that compile easy descriptions of them to about any language. The DSL can be included in repo right next to resultant code for documentation purposes. Hardware designers also synthesize and transform them with automated tools. Given that, the difficulty of doing FSM's by hand should never be a problem for any language. Just don't do it by hand. Automate the tedious stuff machines are good at. Hand-code the stuff humans are good at.
- mbrock 10y ago
  What's the problem with event-driven state machines in Haskell that leads to "complexity disasters"? Maybe you could show an example of a non-disastrous imperative variant, and we'll see if me or someone else can come up with a Haskell translation that isn't disastrously complex?

by nilved 10y ago

Yes. You can model state easily in functional programming languages but the technique is unfamiliar to imperative programmers since it's more explicit. This is a very good thing.

darksaints 10y ago

More explicit? Try more convoluted. Ever try to build an event-driven FSM in Haskell? I've seen several try, including myself...the results of which have all been complexity disasters. Imperative languages in general have poor data structures for representing state (no ADTs!), but nothing is more explicit and straightforward than using mutable data or mutable containers for modeling actual mutable state. That's why languages like Scala exist. Functional without religious paradigm enforcement.

nickpsecurity 10y ago
I don't do FP or Haskell but did do FSM's in imperative languages. Looking up Haskell's event-driven FSM's... https://wiki.haskell.org/Real_World_Applications/Event_Driven_Applications https://wiki.haskell.org/Real_World_Applications/Event_Drive... https://accu.org/index.php/journals/2199 https://accu.org/index.php/journals/2199 ...gives me code that looks weird since I did imperative but straight-forward. The second link even shows some simplicity and less tangling vs imperative examples. I wonder what makes you think FSM's in Haskell turn into disasters if these examples were so easy. Besides, you shouldn't be hand-coding FSM's to begin with. The various sub-fields of programming and IT I've studied all came from different directions to same best practice for FSM's: DSL's that generate them. LISP people did it forever. iMatix did it for reliable, distributed apps in C. Haskell embeddings go from stuff like that up to hard real-time C. Theres also open-source projects that compile easy descriptions of them to about any language. The DSL can be included in repo right next to resultant code for documentation purposes. Hardware designers also synthesize and transform them with automated tools. Given that, the difficulty of doing FSM's by hand should never be a problem for any language. Just don't do it by hand. Automate the tedious stuff machines are good at. Hand-code the stuff humans are good at.
mbrock 10y ago
What's the problem with event-driven state machines in Haskell that leads to "complexity disasters"? Maybe you could show an example of a non-disastrous imperative variant, and we'll see if me or someone else can come up with a Haskell translation that isn't disastrously complex?