There are a number of great answers on StackOverflow as to why Smalltalk wasn't more popular:
http://stackoverflow.com/questions/711140/why-isnt-smalltalk...
Today’s Smalltalk: A Second Look At The First OO Language
11–20 of 52 posts
Re: Today’s Smalltalk: A Second Look At The First OO Language
#12Simula is generaly recognized as the first OO language, so it's a second look at the second OO language at best.
Simula and to a similar extent SketchPad are proto-OO: they planted the seeds many of the concepts that would go into OO, but Smalltalk is where the seeds were first reaped. But at the end of the day, we are arguing about a label, and its hard to tell where proto-X really becomes X (e.g. anthropologists argue about the line between proto writing and writing).
I'm curious what you believe Simula is lacking to make it fully OO.
Re: Today’s Smalltalk: A Second Look At The First OO Language
#13I feel like a lot of the really clever and elegant things about smalltalk as a language and an object model got bogged down in the program image execution model, to the point where it stunted the evolution of those ideas for a long time. We're getting to the point where such a model is more practical now, but it still strikes me as hopelessly impractical even so. It wasn't until OSX made Objective-C take off and Rail…
And yet people are talking about using VM images and the likes of Docker for deployment nowadays.
There is definitely a level where the concept makes a lot of sense, but even with things like docker or vagrant or ec2 images there is still an expectation that you keep around enough information to replicate the image from scratch, be it a shell script or chef or puppet or a dockerfile. Smalltalk's images didn't really have this feature.
Re: Today’s Smalltalk: A Second Look At The First OO Language
#14Simula is generaly recognized as the first OO language, so it's a second look at the second OO language at best.
Correct. Although Smalltalk is generally regarded as the first one because the concept "object orientation" was first used in it. Still, the big thing in Smalltalk are not objects, but messages. That's something many later OO languages missed on completely. From Kay: «OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in S…
I think the reason many later OO languages "missed" messages completely is because the distinction makes little sense in more static languages that lacks a way to dynamically call a method/send a message.
Re: Today’s Smalltalk: A Second Look At The First OO Language
#15Earlier quoted context omitted.
Simula and to a similar extent SketchPad are proto-OO: they planted the seeds many of the concepts that would go into OO, but Smalltalk is where the seeds were first reaped. But at the end of the day, we are arguing about a label, and its hard to tell where proto-X really becomes X (e.g. anthropologists argue about the line between proto writing and writing).
I'm curious what you believe Simula is lacking to make it fully OO.
See http://www.stanford.edu/class/cs242/slides/2007/simula-small....
The main omission is encapsulation.
Re: Today’s Smalltalk: A Second Look At The First OO Language
#16I feel like a lot of the really clever and elegant things about smalltalk as a language and an object model got bogged down in the program image execution model, to the point where it stunted the evolution of those ideas for a long time. We're getting to the point where such a model is more practical now, but it still strikes me as hopelessly impractical even so. It wasn't until OSX made Objective-C take off and Rail…
But only by leaving the image model behind. There are many Smalltalks without an image actually... GNU-Smalltalk, Smalltalk/X and Amber, for instance. GemStone/S uses a mixture between image and filesystem, so it can't be regarded as a traditional image-based system either. The only Smalltalks that still use an image paradigm (that I know of) are Squeak derivatives (Squeak, Pharo, Cuis) and VisualWorks. That said, I…
Both Gnu Smalltalk and Smalltalk/X are able to use images, while GST is optimized for "normal source code" model, in ST/X it's mostly an artifact of implementation and file system resident source code is simply a way to store what essentially amounts to changes file in classical implementations (the killer feature is that you in most common case can use non-ST specific VCS without significant issues). In all I haven't seen ST implementation with good development tools that is not at least partially image based.
The problem I see with ST IDEs is the fact that most advanced features work by introspecting live image state and autogenerating some source code, which completely break any attempts to meaningfully define what is (versionable) programmer-written input and what is derived tool output.
Re: Today’s Smalltalk: A Second Look At The First OO Language
#17[deleted]
Re: Today’s Smalltalk: A Second Look At The First OO Language
#18Earlier quoted context omitted.
But only by leaving the image model behind. There are many Smalltalks without an image actually... GNU-Smalltalk, Smalltalk/X and Amber, for instance. GemStone/S uses a mixture between image and filesystem, so it can't be regarded as a traditional image-based system either. The only Smalltalks that still use an image paradigm (that I know of) are Squeak derivatives (Squeak, Pharo, Cuis) and VisualWorks. That said, I…
Both Gnu Smalltalk and Smalltalk/X are able to use images, while GST is optimized for "normal source code" model, in ST/X it's mostly an artifact of implementation and file system resident source code is simply a way to store what essentially amounts to changes file in classical implementations (the killer feature is that you in most common case can use non-ST specific VCS without significant issues). In all I haven'…
True, they're partially image-based.
In all I haven't seen ST implementation with good development tools that is not at least partially image based.
Re: Today’s Smalltalk: A Second Look At The First OO Language
#19Earlier quoted context omitted.
And yet people are talking about using VM images and the likes of Docker for deployment nowadays.
There is definitely a level where the concept makes a lot of sense, but even with things like docker or vagrant or ec2 images there is still an expectation that you keep around enough information to replicate the image from scratch, be it a shell script or chef or puppet or a dockerfile. Smalltalk's images didn't really have this feature.
I was always told to fileout my work and then filein into a blank image to remove any cruft that accumulates during development. That's pretty much the same?
Re: Today’s Smalltalk: A Second Look At The First OO Language
#20I feel like a lot of the really clever and elegant things about smalltalk as a language and an object model got bogged down in the program image execution model, to the point where it stunted the evolution of those ideas for a long time. We're getting to the point where such a model is more practical now, but it still strikes me as hopelessly impractical even so. It wasn't until OSX made Objective-C take off and Rail…
But only by leaving the image model behind. There are many Smalltalks without an image actually... GNU-Smalltalk, Smalltalk/X and Amber, for instance. GemStone/S uses a mixture between image and filesystem, so it can't be regarded as a traditional image-based system either. The only Smalltalks that still use an image paradigm (that I know of) are Squeak derivatives (Squeak, Pharo, Cuis) and VisualWorks. That said, I…
Dolphin uses images too.