Maybe, but IMO it's often that the abstractions used to build software suck at it. Consider for example UI programming, the UI thread and event loop are hacks done because of lack of tools, performance with the current ones, and legacy environment/design. There is no reason why every event cannot be executed parallel, manipulated as push collections and have event handlers that perform application state transitions as transactions.
>and being able to reason about necessary state is how you do anything useful
I agree, and two parts need to be stressed in this, being able to reason and necessary state. Immutability/values make reasoning part transparent and necessary state is isolated in separate abstractions that again simplify reasoning about them.
I don't know how this applies to Haskell, but from playing with Clojure I can definitely see the advantages of working with values, even with single threaded programming reasoning is much simpler, and state is isolated in to Var/Ref/Atom/Agent primitives that have clear usage patterns and clean semantics (no gotchas with compiler reordering some instruction for lockless programming, no worry about lock acquisition order, etc.)
In my opinion, there isn't really a palpable benefit to be gained from totally re-engineering GUI event handling. Processes that are so CPU intensive they cause the GUI to lag are uncommon (and easily dealt with when they do occur). Even if a re-engineering of the GUI event architecture did occur, that would be a systems level issue, and most developers could remain oblivious.
I like Clojure, I think Rich did a great job with the data structures. My only gripe is that it would be a lot more elegant if the notion of transients went away completely. I think transactions with automatic commit and branching on reference creation would be much nicer (and faster). Still a very well engineered language by and large.
>there isn't really a palpable benefit to be gained from totally re-engineering GUI event handling
Sure but you do agree that the event loop/thread lock is a cumbersome hack due to the system constraints. If the system was based on clojure/functional concepts (with lw threads) it would be natural to implement it that way. And it would hardly be transparent, you deal with event loops and UI thread lock in explicitly.
My experience in user interface coding (though not really my favorite area) has been that event handling is pretty much code and ignore, until you want to do some big nasty thing, at which point you have to implement a callable/runnable interface (in java), queue things up and do some synchronization. This seems to be less of an issue in the browser, though I haven't looked at the implementation details.
I do agree that having some kind of multi-threaded greenlet/fiber dispatcher would be more efficient and handle corner cases better. I just don't think your average developer would notice a huge difference.
Maybe, but IMO it's often that the abstractions used to build software suck at it. Consider for example UI programming, the UI thread and event loop are hacks done because of lack of tools, performance with the current ones, and legacy environment/design. There is no reason why every event cannot be executed parallel, manipulated as push collections and have event handlers that perform application state transitions as transactions.
>and being able to reason about necessary state is how you do anything useful
I agree, and two parts need to be stressed in this, being able to reason and necessary state. Immutability/values make reasoning part transparent and necessary state is isolated in separate abstractions that again simplify reasoning about them.
I don't know how this applies to Haskell, but from playing with Clojure I can definitely see the advantages of working with values, even with single threaded programming reasoning is much simpler, and state is isolated in to Var/Ref/Atom/Agent primitives that have clear usage patterns and clean semantics (no gotchas with compiler reordering some instruction for lockless programming, no worry about lock acquisition order, etc.)