How to fail with GToolkit
We see a lot of people enthusiastically getting started with GToolkit. Some of them stick around, but a lot of them try a few things, make some nice graphs, and then somehow drop out. Why does that happen? Here are some of the hurdles to cross:
Moldable development requires new and other skills
Creating parsers, creating all kinds of visualizations and inspectors, and other tool building is outside the normal scope of skills for a lot of developers. Also, navigating a live system and driving development with integrated executable documentation is not a widespread practice. And they are crucial for being effective in moldable development. The GToolkit book examples are mostly not comprehensive enough to serve as a course in moldable development. It takes time and effort to develop these skills.
The programming environment is large and dense
GToolkit has a rich history. Pharo Smalltalk has been refactored continuously from before it forked from Squeak, so that already consisted of abstractions build up over decades. Then the MOOSE software reengineering environment was migrated and build on top of it, containing lots of research results from decades of code visualization research. With the shift in focus to moldable development and a new graphical stack to enable that, there are even more abilities to provide functionality with very little code. A lot of tools need no more than a few dozen lines of code. That makes it easy to underestimate what GToolkit contains.
It is a live environment
An image based live environment evolves continuously. In that evolution, the image contains at the same time old versions of tools that are supposed to be replaced, current versions, and experiments with new versions or approaches. That makes it difficult for people new to the environment to decide which tool/library to use. The old Morphic graphical stack is still in GToolkit, as are the Pharo Spec tools and Roassal visualizations that build on top of them. The package names that give no direct indication to what functionality is provided, create another barrier to adoption.
Crossing the hurdles
The payoff in real productivity of crossing these hurdles is great though. None of the graphs shown above took more than a few dozen lines of code to create. And they can be used directly in the environment to navigate the system: clicking on one of the circles representing a method (larger methods have a larger circle) directly opens an editor on the method. This makes it easy to visualize and prioritize the work.
