Smalltalk single-handedly invented "the tooling", thanks to the various "browsers" and refactoring and testing tools, all made possible because of the dynamic nature of the language, which made the code almost its own runtime representation.
> the performance
Smalltalk pioneered many JIT techniques in the early '80s.
> the VM, the GC
All Smalltalks, as far as I can tell, are garbage-collected and run in VMs.
> the libraries
As a sibling comment states, that's what you get after decades of usage; can you tell with any certainty that Smalltalk would have less libraries, were it popular for longer?
(Actually, there are objective problems with distributing libraries in Smalltalk, stemming from its "everything in global namespace" nature; there were many systems designed to alleviate this problem.)
> is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human
I'm afraid you don't understand Smalltalk environment in full.
In an ordinary language, the code you write is just text. The type system adds certain information to the bits of text on your screen and prevents you - via compiler errors - from arranging the pieces of text in a way which would probably make the program explode when run.
It works most of the time, except when it doesn't and you end up passing void pointers and Object references. In effect, instead of only dealing with the type system, you have to deal with both static types and runtime behavior. I guess you just like it.
When working with Smalltalk, however, you work in a live environment. In Smalltalk, there is no source. Whatever you write is not just text - it's alive, then and there, and the system can trace each identifier and get its runtime type as you type, including concrete types of polymorphic types and other constructs frequently impossible to check with a static type checker in most languages.
In effect, Smalltalk gives you more contextual information to work with than most statically typed languages. Were you ever puzzled about which overload of a method (of polymorphic classes) will be called in a particular scenario? In Smalltalk, you can just ask the system and it will tell you.
Coupled with other features of the language this makes it really easy to perform automated refactorings. As others noted, the very notion of automated refactorings come from Smalltalk. I'm not very familiar with Java tooling, but I'd be really surprised if it enabled anything more than what Smalltalks offer.
In summary: static type systems are not the only way of adding contextual data to the source. There are other, arguably more powerful (access to the "real" runtime types) ways of doing it, and Smalltalk implements one of it.
Don't worry, though - the misconceptions you hold are very popular and it's not your fault for believing them. The problem with programming is that it evolves pretty rapidly, with many approaches failing along the way, that it's rather impossible to provide a comprehensive summary of the best ideas; and without such a summary we rely mostly on gossip. Moreover, the benefits of some approaches are very hard to grasp without experiencing them first-hand, and who has the time for that?
> I'm afraid you don't understand Smalltalk environment in full.
I'm afraid you don't understand the difference between a statically and dynamically typed language.
I am well familiar with Smalltalk and its image system, I was using it on Sparc and NeXt stations more than twenty years ago.
What you don't understand is that the absence of type annotations (Smalltalk) makes it impossible for automatic refactorings to execute safely. It's mathematically impossible.
Smalltalk's refactoring browser required a lot of human supervision to perform its refactorings. You could turn the prompts off (maybe that's what you did) so you'll have the illusion of an automatic refactoring, but the code you get in the end is unsafe and might be different from the one you started with.
You don't have this problem with a statically typed language, where the automatic refactorings are guaranteed safe.
> Don't worry, though - the misconceptions you hold are very popular and it's not your fault for believing them
Please stop the patronizing tone, I'm pretty sure I know more about this subject than you do, having worked in this field for 40+ years.
You just don't know what you don't know. It's okay, but just don't act superior to random people on the Internet or you'll just look like a fool.
> What you don't understand is that the absence of type annotations (Smalltalk) makes it impossible for automatic refactorings to execute safely. It's mathematically impossible.
What you don't understand - I write this jokingly and let's not escalate this further - is that there are more ways of getting the type information than explicit annotations in the source code.
But, thinking about this, I'm inclined to agree that there are, in principle, fewer safe refactorings possible in a language which relies solely on these "other ways". I of course completely disagree that there are no such refactorings at all, and - additionally - there is no reason that Smalltalk could not allow for some annotations.
Have you seen NewSpeak, a Smalltalk dialect by Gilad Bracha? I admit I was thinking more about it and similar systems than about pure Smalltalk of the '80s. Sorry about the confusion.
> but the code you get in the end is unsafe and might be different from the one you started with.
> You don't have this problem with a statically typed language, where the automatic refactorings are guaranteed safe.
Are you sure that all the refactorings in a statically typed language are safe? Even if the type system is unsound - which it almost always is? I don't believe it to be true, but I can be persuaded otherwise if you present a proof.
> Please stop the patronizing tone
Then please stop stating unconditional superiority of static type systems.
> You just don't know what you don't know.
Indeed. That's normal, though. Still, I'm learning. Please help me in this and provide arguments backed by facts instead of writing in broad generalizations.
> that there are more ways of getting the type information than explicit annotations in the source code
The only way that's been studied is running the code and inferring types based on the runtime behavior of the program.
This is still extremely error prone since you never have a guarantee that these runes are exhaustive enough to present the entire type spectrum that certain objects can receive. Besides, it's also obviously completely impractical (and defeats the purpose) to actually have to run your code before you can gain some type information about it.
No, there is really only one way to acquire the type information necessary for safe automatic refactorings, and it's to have type annotations in your source.
> Have you seen NewSpeak, a Smalltalk dialect by Gilad Bracha? I admit I was thinking more about it and similar systems than about pure Smalltalk of the '80s. Sorry about the confusion.
Yes, I followed NewSpeak when Gilad was working on it but I had little interest in it since Gilad perservered in the dynamically typed approach that is flawed on so many levels. StrongTalk was a more interesting experiment, in my opinion.
> I of course completely disagree that there are no such refactorings at all
There are very few of them, such as renaming a local variable. That's pretty much it. Anything else that goes beyond a very tiny lexical scope is impossible to automate safely.
> Then please stop stating unconditional superiority of static type systems.
It's pretty much a fact today. A decade ago, you could have argued that dynamically typed languages let you prototype faster and are less verbose than statically typed languages.
With today's generation of statically typed languages, these two advantages no longer apply and there is really no good reason to start a large project with a dynamically typed language.
> With today's generation of statically typed languages, these two advantages no longer apply and there is really no good reason to start a large project with a dynamically typed language.
There is lack of evidence for it, especially given that 'today's generation of statically typed languages' is mostly unused and there is very little practical experience. Most of the industry hasn't heard about it and doesn't use it.
Smalltalk single-handedly invented "the tooling", thanks to the various "browsers" and refactoring and testing tools, all made possible because of the dynamic nature of the language, which made the code almost its own runtime representation.
> the performance
Smalltalk pioneered many JIT techniques in the early '80s.
> the VM, the GC
All Smalltalks, as far as I can tell, are garbage-collected and run in VMs.
> the libraries
As a sibling comment states, that's what you get after decades of usage; can you tell with any certainty that Smalltalk would have less libraries, were it popular for longer?
(Actually, there are objective problems with distributing libraries in Smalltalk, stemming from its "everything in global namespace" nature; there were many systems designed to alleviate this problem.)
> is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human
I'm afraid you don't understand Smalltalk environment in full.
In an ordinary language, the code you write is just text. The type system adds certain information to the bits of text on your screen and prevents you - via compiler errors - from arranging the pieces of text in a way which would probably make the program explode when run.
It works most of the time, except when it doesn't and you end up passing void pointers and Object references. In effect, instead of only dealing with the type system, you have to deal with both static types and runtime behavior. I guess you just like it.
When working with Smalltalk, however, you work in a live environment. In Smalltalk, there is no source. Whatever you write is not just text - it's alive, then and there, and the system can trace each identifier and get its runtime type as you type, including concrete types of polymorphic types and other constructs frequently impossible to check with a static type checker in most languages.
In effect, Smalltalk gives you more contextual information to work with than most statically typed languages. Were you ever puzzled about which overload of a method (of polymorphic classes) will be called in a particular scenario? In Smalltalk, you can just ask the system and it will tell you.
Coupled with other features of the language this makes it really easy to perform automated refactorings. As others noted, the very notion of automated refactorings come from Smalltalk. I'm not very familiar with Java tooling, but I'd be really surprised if it enabled anything more than what Smalltalks offer.
In summary: static type systems are not the only way of adding contextual data to the source. There are other, arguably more powerful (access to the "real" runtime types) ways of doing it, and Smalltalk implements one of it.
Don't worry, though - the misconceptions you hold are very popular and it's not your fault for believing them. The problem with programming is that it evolves pretty rapidly, with many approaches failing along the way, that it's rather impossible to provide a comprehensive summary of the best ideas; and without such a summary we rely mostly on gossip. Moreover, the benefits of some approaches are very hard to grasp without experiencing them first-hand, and who has the time for that?