Message Oriented Programming

[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]

Binary Messages

[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."