4 ms·

Are there any perceived shortcomings of Smalltalk that caused it not to take hold?

xkriva11 5y ago
To really take advantage of its strengths, one needs to adopt to a completely new IDE and way of working, which puts a lot of people off. On the other hand, if it were adopted to behave like all other environments, there would be objections again, "It's exactly the same as what I'm using now. So why switch?" It should be added that Pharo addressed most of the small problems that the original Smalltalk had.
- igouy 5y ago
  Most of the small problems but not the big problems ? :-)
  - xkriva11 5y ago
    :-)
crdrost 5y ago
So, Smalltalk is radically different from other programming languages, and has a very different vision for what it means to program. Imagine that you download the binary for the programming language, and then you don't know what to do with it so you double click it or try to execute it from the shell, and you are very surprised to see a window open up, showing something looking like a blank desktop. What is this? You go off to read some tutorials, they show you some ways to click inside the window and so forth. It slowly dawns on you: this is your program. It is running as we speak. You are livecoding it, those button clicks are mutating it to do new things. The reason it's not doing anything is you haven't written it yet, and it's inviting you to, and when you do it'll recompile and show you the new thing instantly. So your programming languages have always been designed like a circuit board or a 3D printing rig. Lots of files of blueprints, and then the robots will assemble it for you. Smalltalk is different, the mental model is more like clay or Lego, the thing is already built and running in front of you, what are you going to mold it into being? This different vision means that usually you are editing text not from vim or emacs or VS Code, but from the editing widgets inside of the programming language. Those are part of the clay, and are editable too. Similarly, Smalltalk version control was typically exposed inside of the running system rather than outside. My favorite example of this, the thing that is maybe the most outrageous if you're in a normal programming language, is Object.become(). This is a runtime dependency injector. “I want to instruct the programming language to take all of the traffic that it was sending to that object, and send it to me instead. I will become that object.” If you are used to Java where my constructor instantiates some dependency object and I save it to a private variable in this object, surely you see this as a safety violation. “What do you mean, that anybody who gets a reference to this object can tear it out of my private property and replace it with some other subclass? I made it private so I could control when that field gets set! How dare you?” It’s not, of course. And this is available for every object in the system, which is why you can do this modeling by clay. They tried to write as much of Smalltalk as possible in Smalltalk and so you can just see the source code of the programming language in the source code browsers that you can call up from this window, and you can live edit any of that, and Smalltalk will compile your new object and swap it into where the built-in object was. Put a different way, it's not a safety violation because this is how modern development with microservices and kubernetes actually works. Security is people's ability to surprise you, measured in dollars: part of this definition is, Smalltalk developers are not surprised by their ability to do this. Every “object” is thought of as a separate server with an API, and of course I will replace old servers with new ones and tell the load balancer to send traffic my way.
igouy 5y ago
There were "perceived shortcomings" although Smalltalk use seems to have grown in the decade following. IBM taught "object-oriented software technology to experienced procedural programmers" and studied that experience — 'We read and heard many stories about confident and experienced programmers' plunging into self-study tutorials, only to give up in frustration after several hours, still wondering, "Where is the application code?" … New programmers often became lost in the hierarchy or spent considerable time in unfocused exploration of the interactive tools.' https://mitpress.mit.edu/books/making-use https://mitpress.mit.edu/books/making-use Technical shortcomings, September 1988 — "… currently unrealistic to expect that an excellent rapid prototyping system can also be an excellent application delivery system." https://static.miraheze.org/triplescriptswiki/4/49/Wirfs-Brock_and_Wilkerson_-_1988_-_An_Overview_of_Modular_Smalltalk.pdf https://static.miraheze.org/triplescriptswiki/4/49/Wirfs-Bro... "Smalltalk, C++ knock heads. Computerworld 29, 45 (Nov. 6, 1995) https://books.google.com/books?id=oKDIlxbMaS4C&pg=PA153 https://books.google.com/books?id=oKDIlxbMaS4C&pg=PA153

To really take advantage of its strengths, one needs to adopt to a completely new IDE and way of working, which puts a lot of people off. On the other hand, if it were adopted to behave like all other environments, there would be objections again, "It's exactly the same as what I'm using now. So why switch?" It should be added that Pharo addressed most of the small problems that the original Smalltalk had.

igouy 5y ago
Most of the small problems but not the big problems ? :-)
- xkriva11 5y ago
  :-)

crdrost 5y ago

So, Smalltalk is radically different from other programming languages, and has a very different vision for what it means to program. Imagine that you download the binary for the programming language, and then you don't know what to do with it so you double click it or try to execute it from the shell, and you are very surprised to see a window open up, showing something looking like a blank desktop. What is this? You go off to read some tutorials, they show you some ways to click inside the window and so forth. It slowly dawns on you: this is your program. It is running as we speak. You are livecoding it, those button clicks are mutating it to do new things. The reason it's not doing anything is you haven't written it yet, and it's inviting you to, and when you do it'll recompile and show you the new thing instantly. So your programming languages have always been designed like a circuit board or a 3D printing rig. Lots of files of blueprints, and then the robots will assemble it for you. Smalltalk is different, the mental model is more like clay or Lego, the thing is already built and running in front of you, what are you going to mold it into being? This different vision means that usually you are editing text not from vim or emacs or VS Code, but from the editing widgets inside of the programming language. Those are part of the clay, and are editable too. Similarly, Smalltalk version control was typically exposed inside of the running system rather than outside. My favorite example of this, the thing that is maybe the most outrageous if you're in a normal programming language, is Object.become(). This is a runtime dependency injector. “I want to instruct the programming language to take all of the traffic that it was sending to that object, and send it to me instead. I will become that object.” If you are used to Java where my constructor instantiates some dependency object and I save it to a private variable in this object, surely you see this as a safety violation. “What do you mean, that anybody who gets a reference to this object can tear it out of my private property and replace it with some other subclass? I made it private so I could control when that field gets set! How dare you?” It’s not, of course. And this is available for every object in the system, which is why you can do this modeling by clay. They tried to write as much of Smalltalk as possible in Smalltalk and so you can just see the source code of the programming language in the source code browsers that you can call up from this window, and you can live edit any of that, and Smalltalk will compile your new object and swap it into where the built-in object was. Put a different way, it's not a safety violation because this is how modern development with microservices and kubernetes actually works. Security is people's ability to surprise you, measured in dollars: part of this definition is, Smalltalk developers are not surprised by their ability to do this. Every “object” is thought of as a separate server with an API, and of course I will replace old servers with new ones and tell the load balancer to send traffic my way.

igouy 5y ago

There were "perceived shortcomings" although Smalltalk use seems to have grown in the decade following. IBM taught "object-oriented software technology to experienced procedural programmers" and studied that experience — 'We read and heard many stories about confident and experienced programmers' plunging into self-study tutorials, only to give up in frustration after several hours, still wondering, "Where is the application code?" … New programmers often became lost in the hierarchy or spent considerable time in unfocused exploration of the interactive tools.' https://mitpress.mit.edu/books/making-use https://mitpress.mit.edu/books/making-use Technical shortcomings, September 1988 — "… currently unrealistic to expect that an excellent rapid prototyping system can also be an excellent application delivery system." https://static.miraheze.org/triplescriptswiki/4/49/Wirfs-Brock_and_Wilkerson_-_1988_-_An_Overview_of_Modular_Smalltalk.pdf https://static.miraheze.org/triplescriptswiki/4/49/Wirfs-Bro... "Smalltalk, C++ knock heads. Computerworld 29, 45 (Nov. 6, 1995) https://books.google.com/books?id=oKDIlxbMaS4C&pg=PA153 https://books.google.com/books?id=oKDIlxbMaS4C&pg=PA153