And I actually find things like Spotter, Code Rewriter, GTInspector and Calypso pretty neat.
IntelliJ is not simpler and is closed source. It is neat, true. We even use its icons in Pharo.
And that's the problem. The tools are different. They require learning. And once learned, they are only useful for dealing with one language. And that is a language that nobody around me uses.
The result is a barrier to entry. A barrier to entry of a type that I'm not bothering with again unless I have a good reason to.
Furthermore the small size of the community means that I am unlikely to get to choose tools that fit me. I'll be stuck with whatever the personal preferences were of the people who wrote the tooling. Even if I like them, my neighbor probably won't.
You bring up IntelliJ. However I don't use IntelliJ. I prefer vi and command lines. The guy sitting across from me likes Visual Studio. I couldn't tell you how many other IDEs are in use by programmers in the same space as me. No single toolset is going to be to all of our tastes. And it doesn't matter with a filesystem based language, because we are each free to use whatever we want.
User experience is one area where Smalltalk seems like it could use some focus on. Compare the screenshot of the system browser on pharo.org compared to figure 17.1 (page 293, PDF page 315) of the "blue book":
http://sdmeta.gforge.inria.fr/FreeBooks/BlueBook/Bluebook.pd...
Apparently that layout was perfected in 1980. Has anyone ever experimented with showing more than one method at a time in a window? And taking up less screen real estate with the class hierarchy? Seems ripe for some new thinking here.
And working on a fuse thing that exposes my running image as a filesystem so that I can such tools as well.
But saying that the tools are different and you cannot be bothered to use them? Look, Visual Studio is a monster beast, with tons and tons of features, including Azure ones. It takes a serious while to master.
And vim also takes a serious while to use well. Especially when we use a couple of plugins.
An engineer knows the tools. Then a specialist masters them. The master makes them. Or changes them.
Pharo allows one to do that. Without strings attached.
The benefits of learning a particular tool are essentially proportional to how often you use that tool. The greater flexibility of other tools such as vim means that the cost of learning it can be amortized over essentially as many projects as you wish. The costs for learning Pharo tooling are only spread over as many Pharo projects you do. If you don't believe you'll be doing all that much in Pharo, it makes it a fairly daunting proposition to invest that time.