I hope not. What are we trying to optimize?
If you look closely at the GT work, you might notice that it is not just a tool, it's a whole new philosophy for coding. The EyeInspector picked only one aspect out of a whole.
One high goal is to change programming such that the inspector + debugger to capture most of the coding experience. This is what live means. Right now, in the default Pharo we only code small things in the debugger and nothing in the inspector. We work on the idea of a moldable IDE that will change all that.
Let's look at some facts. Right now, in my image I have 75 different extensions for GTInspector. And the total amount of lines of code has barely passed 1000 LOC (including all utility code). These are not just independent views, but they are combinable. The amount of use cases supported span a wide range: querying source code, visualizing performance, navigating file system, querying DB, and more (read the posts from
humane-assessment.com for hints in this direction).
We programmed most of these extensions from within the inspector both because it's fun and because it's significantly more productive. And I am not the only one. This power is not serendipity, it's by design. And we only started to untap this potential.
There is still a long way for the concept of inspector and I believe there is a large payoff in it, too.
Optimizing for a small thing now should not be the way to go :)
Cheers,
Doru