RationalismVsEmpiricism
From APIDesign
m (RationalismVsEmpriricism moved to RationalismVsEmpiricism: Typo) |
|||
| (8 intermediate revisions not shown.) | |||
| Line 3: | Line 3: | ||
=== AWT Dispatch Thread shall be used only for painting === | === 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 | + | 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: | That started a discussion about proper way to fix it. One proposed solution suggested: | ||
| Line 11: | Line 11: | ||
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. | 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]]). | + | 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. | ||
| - | 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 | + | 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 [[empiricism|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. |
| + | |||
| + | === Summary === | ||
| - | [[Rationalism]] is mentally attractive, but during real | + | [[Rationalism]] is mentally attractive, but during real development we end up at most with [[empiricism]], if not with plain [[cluelessness]]. |
Current revision
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.
Summary
Rationalism is mentally attractive, but during real development we end up at most with empiricism, if not with plain cluelessness.
Follow
