Live data from Hacker News

Today’s Smalltalk: A Second Look At The First OO Language

blog.smartbear.com

1–10 of 52 posts

Re: Today’s Smalltalk: A Second Look At The First OO Language

#3

Simula 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 Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.»

Re: Today’s Smalltalk: A Second Look At The First OO Language

#4
I 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 Rails made Ruby take off that some of the fundamental language features entered the mainstream, and they did so with a gusto that other 'ivory tower' languages wish they could achieve. But only by leaving the image model behind.

It seems like something like Erlang managed to do what Smalltalk tries to do with the image better, allowing for easier to reason about deployment, collaboration, and version control while still letting you deal with a system of relatively opaque boxes of replaceable code.

Re: Today’s Smalltalk: A Second Look At The First OO Language

#5

I 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…

Funny you should mention Erlang, as I think that in its own way, it's treading the lisp/smalltalk path of getting a few things really, really right, and being head and shoulders better for certain kinds of applications. And yet, at the same time, doomed to sooner or later have enough of its goodies ripped off by programming languages that are more mainstream, that will far surpass it in functionality. Go and Scala, for instance, nabbed some of the concurrency stuff, although Go is still missing some of what makes Erlang really distinct.

Re: Today’s Smalltalk: A Second Look At The First OO Language

#6

I 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 believe the image is a very valid model, and I prefer working on a Pharo environment than anywhere else. However powerful text editors, IDEs and debuggers may be, you can never reach the same level of integration between tools and system if your tools, your language and your system are not the exact same thing.

Re: Today’s Smalltalk: A Second Look At The First OO Language

#7

I 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.

Re: Today’s Smalltalk: A Second Look At The First OO Language

#8

Simula 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).

Re: Today’s Smalltalk: A Second Look At The First OO Language

#9

I 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…

Back in the early 90's Smalltalk was actually starting to be used in the enterprise, but then came Java.

We had access to VisualWorks at the university back then.

Many developers aren't aware that Eclipse roots are in Visual Age for Smalltalk. Also that Eclipse's workspace concept was an attempt to create a virtual image out of files.

Having said this, Smalltalk's image was a problem in the time when VMs weren't that mainstream in the industry.

Additionally many of modern image based source control systems weren't available back then.

Post reply on HN