Of course, optimizing for experience is never going to work out for everyone. My point was that as a side effect of developers experimenting (and Smalltalk being initially optimized for experimentation) Smalltalk became more optimized for developers and developer experience than most other environments. Working in other environments, there are things that are worth looking at to see if those features and capabilities can be emulated, or whether in specific situations the ease of use overcomes the niche status of the language sufficiently to make it worth considering.

If you’re a physicist, you’ll probably prefer the experience of developing in Haskell. C programmers as a group (with the inevitable exceptions) will probably never enjoy something like a modern implementation of Smalltalk. Those who are tied to programming in a REPL environment will continue to prefer languages based around a REPL, etc. None of those are invalid reactions given the context and/or background, but it’s been a long time since a text editor / file manager or a REPL were innovative tools for development.

The developer interface in Pharo called (sardonically, I hope) the Glamorous Toolkit, the morphs used in eToys (yes it’s Squeak, but Squeak and Pharo remain somewhat tied, as many new features in each get quickly ported to the other), and the new layers bloc and brick in Pharo create a wealth of options for both developer experience and user experience. I didn’t go into the latter in the article because it was a different topic, really, and because I find the various current Smalltalk’s have a combination of good user experience features and face-palm user experience failures, but with Swing, WPF, SWT, QT etc. having very little to offer in terms of new development, user experience may be an area where Smalltalk can expand its niche. I’m told the user experience of the Russian bank machines for instance, done in Pharo, are far superior to those done (now largely in HTML) by western banks, and it’s possible to do your yearly taxes in less than 15 minutes at a Russian bank machine.

Thanks for mentioning the use cases Eiffel does have. I simply wasn't aware of them, and I’m glad it has them. It’s a gorgeous language design-wise and as an object programmer I’m happy to see well done object languages remain in circulation.

I think my point still stands that without being optimized for something perhaps still niche, but less niche than the areas Eiffel continues to be used in, it’s unlikely to garner any interest that might expand those niches in a radical way. Other languages that continue to exist and have specific though rather tiny niches include the language I started with eons ago, FORTH, and APL, the first language based around a REPL, but neither are really relevant unless you happen to be in that specific niche.