5 ms·
To the extent that I understand your complaint, there is a functional architecture that alleviates this concern: arrowized functional reactive programming. http
by pseudonom- 6y ago
To the extent that I understand your complaint, there is a functional architecture that alleviates this concern: arrowized functional reactive programming. https://blog.jle.im/entry/intro-to-machines-arrows-part-1-stream-and.html https://blog.jle.im/entry/intro-to-machines-arrows-part-1-st... talks about it.
- kingdomcome50 6y agoDoes this solve the problem though? I'll be honest, I'm not very familiar with Haskell (and frankly only casually use FP in general), but I don't see how the pattern in your link alleviates my concern. The problem (truly the problem) is about _where_ one defines behavior. It's the expression problem (EP) at its core. A FP approach separates data and behavior in a way that makes adding new behaviors to the same data types easy and OOP combines them in a way to make adding new data types to the same behaviors easy. It's literally the difference between: let model' = update model msg and: let model' = model.update msg Like I said, I don't know Haskell very well (and had a hard time grokking the link), but any purely functional language will suffer from the former over the latter. The side of the EP a language falls on is simply as a matter of the data types/type system available.
- pseudonom- 6y agoAhh, I was focusing on the "local state" vs "global state" bit. Haskell has ways to address the expression problem: e.g. http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCa... and http://okmij.org/ftp/tagless-final/course/lecture.pdf http://okmij.org/ftp/tagless-final/course/lecture.pdf