4 ms·
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 caus
by NathanRice 15y ago
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.
- moonchrome 15y ago>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.
- NathanRice 15y agoMy 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.