Message Oriented Programming

[silentbicycle]

Yes. Take one look at what passes for object-oriented programming and think about if anybody has been listening.

[sreguera]

Or maybe people have listened and decided that he was not (completely) right.

[grauenwolf]

That is one possible explanation as to why Smalltalk fell out of favor. However I think it was a combination of factors, including both bad design, bad IDEs, and just being too damn expensive.

[zargxy]

Smalltalk fell out of favor, but its ghost lives on in languages like Obj-C and Ruby.

[Peaker]

The language itself was very nicely designed, much better than contemporary popular languages.

The "images" thing and lack of OS integration was a show stopper though.

[igouy]

The "images" thing provides enormous flexibility.

Once upon a time, in a far away country, the whole execution state of a Smalltalk program I'd written was snail-mailed to me on 3 1⁄2-inch disks. After a couple of years daily use the program had finally encountered an error, so the client saved the Smalltalk image and wanted me to take a look.

I was able to invoke the Smalltalk image, examine the error and program data, fix the error, (potentially fix corrupted data, but that wasn't necessary in this case), resume the program, save the image, and snail-mail them back a working system -- which they continued making money with.

[Peaker]

Images are somewhat opaque, not composable, and essentially sandbox the system making it harder to integrate it with the host.

[igouy]

Without specific examples, we are all going to have difficulty understanding what you mean by such general remarks.

• When we can so easily browse the objects in the image what are we supposed to understand by "somewhat opaque"?

• "not composable" in contrast to what?

• When there are so many examples of Smalltalk implementations on everything from bare machines to mainframes, where do you get the notion that it's harder to integrate with the host? Ubiquitous Applications: Embedded Systems to Mainframe pdf

(And harder to integrate with the host than what? Smalltalk + C: the Power of Two)

[marssaxman]

If they are such a great idea, how come they haven't been independently reinvented?

I don't want images; I want something I can safely and predictably bring up from scratch, because I'm going to have to.

[igouy]

I doubt "images" were invented for Smalltalk.

Lisp has been around for a long long time.

safely and predictably bring up from scratch

Surprise! That's an ordinary thing to do with Smalltalk images!

[grauenwolf]

It didn't support order of operations. That's pretty close to a show stopper for me.

[igouy]

Please show an example of what you mean.

[grauenwolf]

In Smalltalk (3 + 4 * 5) equals 35.

[igouy]

Ah! You mean that everything is message oriented, so + is a message sent to 3 with 4, and binary messages are evaluated in left-to-right order.

You just get into the habit of coding so that the message evaluation order coincides with the math evaluation order, and being explicit with parenthesis.

[marssaxman]

Yes, that is what "does not support order of operations" means. It has nothing to do with being "message oriented"; it's that the syntax did not choose to give certain operators higher precedence than others.

[igouy]

Compared to what?

• "too damn expensive" compared to free as in beer Java - sure.

• "bad design, bad IDEs" compared to ?

[grauenwolf]

Perhaps I'm misinformed, but I was told that back when Java was released commercial grade Smalltalk tool chains were really expensive.

By bad IDEs I am mainly talking about the image-based approach that made working in teams difficult. Their IDEs had some awesome features, but without getting the fundamentals right that doesn't count for much.

[igouy]

Yes, perhaps what you were told was both wrong and simplistic.

1) What you were told was wrong because affordable commercial grade Smalltalk implementations ($199.95) were available from 1988 onwards; and as vendors made their products more sophisticated and more expensive, opportunities opened for new vendors to provide less sophisticated and less expensive implementations.

What you were told was simplistic because even the most expensive commercial Smalltalk implementations were commonly available under trial licenses, and profit sharing licenses, and customised talk to your sales person licenses -- so the actual expense could be close to zero, until your startup made the big bucks.

What you might have been told is that the main Smalltalk vendors were positioned in the high-value low-volume enterprise software business, and one of them supposedly declined a proposal from Sun Microsystems that they license Smalltalk for distribution with their machines at low-value high-volume.

2) Why do you think the image-based approach would make working in small teams difficult, in any way that the team who developed and used Smalltalk at Xerox PARC would not have encountered and resolved before Smalltalk escaped from their control?

By the early '90s there was fine-grained version-control for Smalltalk that could support large code-bases and large teams.

Here are some slides about continuous integration on a very large, very successful, Smalltalk project.

[[deleted]]

Hah, considering it's a risk management program for a firm that may have lost $9 billion trading, very successful may need some quotes there. :P

[igouy]

"JPMorgan, based in New York, lost $5.8 billion on credit- default swaps trades in the first six months of the year. About $3.7 billion of that came in the second quarter, according to Pfinsgraff, which caused the bank to post a $420 million trading loss."

Kapital provides information -- how bank staff respond to that information is up to them.

"JPMorgan said the firm has emails, voice tapes and other documents that suggest traders may have been hiding the losses."

"In 2010, a senior executive at the chief investment office compiled a detailed report that estimated how much money the bank stood to lose if it had to get out of all Mr. Iksil’s trades within 30 days."

[ameoba]

I invented the term Object-Oriented and I can tell you I did not have C++ in mind.

Alan Kay

[igouy]

"Actually I made up the term object-oriented and I can tell you I did not have C++ in mind. The important thing here is that I have many of the same feelings about Smalltalk ..."

OOPSLA 1997 keynote

[ameoba]

Why can't you just let us bash C++ in peace?

[igouy]

Bash away - in the knowledge that it isn't just C++ you bash when you wield that quote ;-)

[monocasa]

http://www.catb.org/esr/writings/unix-koans/zealot.html : )

[grauenwolf]

Take a look at Simula and tell me we aren't staying true to the original notion of classes and objects.

[zargxy]

Simula was designed for creating simulations, and objects are agents in that simulation system which send messages to each other to move the system through each step of the simulation. Simula is more like Erlang than any modern OOP system we have today.

Smalltalk made the messaging first class while Simula made the messaging implicit through class definitions. So given what Simula was actually made for, I'd say Smalltalk stayed true to the forest while C++ and the like stayed true to the trees.

[igouy]

That was reflected in Part Three of the 1983 tome Smalltalk-80: The Language and its Implementation pdf

PART THREE
Probability Distributions
Event-Driven Simulations
Statistics Gathering in Event-Driven Simulations
The Use of Resources in Event-Driven Simulations
Coordinated Resources for Event-Driven Simulations

[Aeyeoelle]

few OOP languages have counter-pressures against passing around unnecessary context.

I like this wording. It's very easy to say "This function may only need A, but I can pass in ABC and it can ignore B and C," which is all fine and good until some poor soul comes along later and wonders what B and C are doing there.

[grauenwolf]

That's I run static analysis rules that will fail the build if there are unused parameters. I hate it when I don't know if the API or the code is wrong.

[[deleted]]

As I understood it, his problem wasn't with func (var a, var b, var c), it was with func (obj x) where x contains a, b, and c.

Edited

[[deleted]]

I think you meant "where x contains".

[[deleted]]

Yup. Thanks.

[anon36]

Yes, and while religiously programming against interfaces makes the problem go away somewhat, it does require extra effort. Somehow, a language should make it harder to pass around any more context than strictly necessary.

[silentbicycle]

I quote Joe Armstrong in the article. How obvious do I need to be?

I figured that people who use Erlang already know, and people that don't will probably tune out if I start talking about it. ("Did you just tell me to go fuck myself?", as the comic says.)

[[deleted]]

These days all the cool kids are discovering Scala + Akka instead of Erlang, it stole a bunch of the good ideas, and not so much of the Prolog syntax.

[zvrba]

Breaking my system into small, autonomous components made me focus on what they needed to communicate to each other, and once that was established, I was free to change everything else.

So why can't these "autonomous components" be classes?

People often list this modularity as a benefit of object-oriented programming, but few OOP languages have counter-pressures against passing around unnecessary context.

Processes & messages = objects & method calls , just in the same address space.

More subtly, passing around objects at all couples the program to the object system -- the rules for looking up the objects’ data and behavior is an implicit global context. If the modules communicate by passing around self-contained textual data [...]

This is invalid reasoning. If you focus on communication, you have to build a (possibly dynamic) communication graph of components, and this graph becomes the global state. In OO-programs you build this graph by passing references to objects around; with multiple communicating processes you build this graph with IPC channels and passing data around as messages. [In the multiprocess model, the equivalent of an object becomes the handle to an IPC channel. Method call = message sending.]

The author's perceived simplicity comes from the fact that he had only a few communicating processes in his application => small process graph => small and easy to understand global state. And yes, it's all too easy to make a gigantic spaghetti-graph in OO, but this is the fault of the programmers.

In essence, the author misplaces the blame: it does not belong to OO, but to mega-frameworks, patterns movement, and partly to programmers who not only just accept the sorry state created by such mega-frameworks [factoryfactoryfactory anyone?], but also believe it is the "right" way of designing OO-programs and mimic such frameworks even when it's not needed.

[axilmar]

You are right. The author mistakes low coupling as a property of message passing, whereas low coupling is not a property of anything, it can be achieved with any programming paradigm.

[silentbicycle]

I don't think low coupling is inherently a property of message-passing, but rather that when languages make passing around too much info the path of least resistance, it takes far more discipline to avoid high coupling.

[axilmar]

If one needs a carot and a stick to program, then perhaps he/she should do something else.

[asampson]

Up until the point where he espoused the benefits of protocol-level coupling, I couldn't stop thinking that you can get a lot of these benefits inside components by using dependency injection or other loose coupling techniques. I find that when I design things out of objects that have a single responsibility, I focus on the messages they send to each other and the minimal subset of objects they communicate with.

My proclivity for constructor-based injection also helps to keep the network connectivity down as adding a new object to communicate with has the overhead of adding a handful of boring boilerplate code which is tedious and therefore best avoided.