RationalismVsEmpiricism
From APIDesign
| Line 12: | Line 12: | ||
One of the distinguished members of [[NetBeans]] community however (quite convincingly) argued in favor of polishing the whole event handling model claiming that '''AWT Dispatch Thread shall be used only for painting'''. I really like this idea. It is so [[rationalistic]]! We know that there are problems in blocking the essential [[Swing]]'s resource (its dispatch thread) for too long and thus we shall design proper mechanism to eliminate this (something like [[SwingWorker]]). Then we shall rewrite all the [[NetBeans]] code to use this and then the world would be more [[beautiful]] place (indeed, as it would be [[rationalistic]]). | One of the distinguished members of [[NetBeans]] community however (quite convincingly) argued in favor of polishing the whole event handling model claiming that '''AWT Dispatch Thread shall be used only for painting'''. I really like this idea. It is so [[rationalistic]]! We know that there are problems in blocking the essential [[Swing]]'s resource (its dispatch thread) for too long and thus we shall design proper mechanism to eliminate this (something like [[SwingWorker]]). Then we shall rewrite all the [[NetBeans]] code to use this and then the world would be more [[beautiful]] place (indeed, as it would be [[rationalistic]]). | ||
| + | |||
| + | === Beauty vs. Solution === | ||
My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up. | My own [[rationalistic]] half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the [[NetBeans]] release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up. | ||
Revision as of 06:52, 15 September 2023
Those of you who have heart about my book know that I have spend almost one chapter in a discussion of the way modern software is built. Those who read that part also know that I started with a really historical point of view and explained the modern practices as a result of fight between Rationalism and Empiricism. I have new experiences to share about their never ending clash.
AWT Dispatch Thread shall be used only for painting
During the work on NetBeans 6.8 the performance team introduced new tool: Slowness Detector. It allows us to observe real UI Responsiveness problems that our users are facing. This is following the spirit of empiricism - observe, measure and only then explain or take some action. And we needed some action as (to some body's surprise, to someone's expectation) actions that were supposed to be instant some time took many seconds.
That started a discussion about proper way to fix it. One proposed solution suggested:
- if the action takes less than 100ms, let it run and do nothing
- if it exceeds this limit, show wait cursor
- if the time accidentally gets higher than few seconds display cancellable modal dialog with progress
This solution is not going to make anything faster (obviously it is just UI Responsiveness work), it just properly indicates the status to the user and offers the additional benefit of being able to stop waiting for end of the operation.
One of the distinguished members of NetBeans community however (quite convincingly) argued in favor of polishing the whole event handling model claiming that AWT Dispatch Thread shall be used only for painting. I really like this idea. It is so rationalistic! We know that there are problems in blocking the essential Swing's resource (its dispatch thread) for too long and thus we shall design proper mechanism to eliminate this (something like SwingWorker). Then we shall rewrite all the NetBeans code to use this and then the world would be more beautiful place (indeed, as it would be rationalistic).
Beauty vs. Solution
My own rationalistic half really wants the above approach to be implemented. However when the other half imagines how much existing code would have to be fixed, how much time that would take, how the NetBeans release schedule would be affected, how many complains we would hear from our fellow developers, then the whole of me just has to give up.
We had a lot of problems to convince our developers that Slowness Detector is useful. And Slowness Detector is really different story, as it delivers throughout reports about each individual failure (it empiristicaly observes) and only the most annoying ones need to be fixed. I cannot imagine the welcome ceremony if I even tried to convince them to sign for a rationalistic approach and use the dispatch thread only for painting. No chance at all.
Rationalism is mentally attractive, but during real development we end up at most with empiricism, if not with plain cluelessness.
<comments/>
Follow
