> the integrated IDE/program experience, which Ruby, Python, Elixir do not give.
True, but be aware that Java IDE's give you ten times more features and refactorings than Smalltalk IDE's can ever give you, because of the simple fact that Smalltalk is dynamically typed (which means it's pretty much impossible for them to provide automated refactorings: most of these need to be supervised by a human).
I am aware, my point still stands: the refactorings available in Java IDE's are more powerful, safer and more numerous than the Smalltalk IDE ever offered.
Which shouldn't come as a surprise since Smalltalk is dynamically typed, which means automated refactorings are impossible to achieve without human supervision.
A Smalltalk image/IDE being dynamically typed doesn't mean anything, as it can have a full live-above-AST-level knowledge of everything in the program -- including the dynamic types of everything.
Think of it as ten times the power of Java's reflection.
What you can do in such a system (without human intervention) makes IntelliJ/Eclipse look like Pico.
It's not the same. With a Smalltalk system, there isn't really an operating system. All activity we would normally ascribe to an OS is simply implement in the Smalltalk environment, using Smalltalk objects, running in a live image. I recommend checking out the Smalltalk-80 "Blue Book", which is beautifully written. You can also play with Pharo too, just be sure to understand that it's adapted for modern personal computers and therefore has to run as a virtual machine. A system that could run Smalltalk natively would be much better.
1) the integrated IDE/program experience, which Ruby, Python, Elixir do not give.
2) the totally orthogonal and very limited set of concepts that build up to the full language. Something that Ruby, Python and Elixir also don't have.
In Smalltalk even a for, if etc statement is not something special to the language. In a way it has fewer special forms than