3 ms·

The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... Also, Smalltalk is dynamically typed so there are very few refactorings that can

The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... Also, Smalltalk is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human.

scroot 9y ago
> The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... None of that emerged from whole cloth in the beginning. It's the result of time and wide adoption. Java was released for free. Smalltalk wasn't.
klibertp 9y ago
> The tooling ecosystem 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?
- hota_mazi 9y ago
  > 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.
  - klibertp 9y ago
    EDIT: rewrote the comment > 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.

scroot 9y ago

> The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... None of that emerged from whole cloth in the beginning. It's the result of time and wide adoption. Java was released for free. Smalltalk wasn't.

klibertp 9y ago

> The tooling ecosystem 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?

hota_mazi 9y ago
> 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.
- klibertp 9y ago
  EDIT: rewrote the comment > 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.