Fog Creek Software
Discussion Board




Smalltalking and Heavy Metal


I have a 1980 Byte magazine issue dedicated to Smalltalk (with balloon on the cover) and predicting the use of message passing systems as the way of building intelligent and responsive software in the future, our well by now.

I was hooked.

At least I think it was 1980, its hidden behind another 8' tall bookcase of science fiction in the garage.

In any event I ended up working for computer manufacturers and software publishers wedded to the Digital Research, then Microsoft (then DRI again) view of doing things and Smalltalk didn't figure at all.

Rationally I always preferred the idea of objects sending and receiving messages to achieve some system, of building objects that could organise themselves into doing the work.  It feels a far more efficient system than having to know fairly intricate things about objects, their methods and properties and fiddling with them directly.

Yes, there's all the Windows UIs each of them using some kind of message queue, but really they're just a way of serialising behaviour.  In that sense each application is only one or two objects, the rest is procedural.

So why didn't Smalltalk and its methodology flourish and supercede the rather leviathan C++ structures and pointers larded over with interfaces to get objects to cooperate?

I did try a few times to plug into the message processing model,  I frequently use timers to set processes off within an application that message other parts of the application especially if there's some kind of real time or process as soon as requirement.

I've even tried things like Objecttalk http://www.iasadvance.com/ but although the messaging was efficient the overhead on top of an interpreted language was too high.

I know Adele Goldberg and Dan Ingalls received the Dr Dobbs award last year but around 25 years after they and Alan Kay proposed creating software the way the world works we still don't have a compelling application or platform that uses it.

And other than Microsoft and Apple didn't buy into it (ok, Apple did a bit) I can't think of a good reason.

Simon Lucy
Saturday, May 03, 2003

While message passing as a pure implementation didn't take over the world, I think the Metaphor certainly did.

The Win32 api, Java, .Net - these all use the same metaphor even though implementation differs.

I think that the main reason for this is performance.  You can get most of the benefits of a message passing implementation using a mixed implementation with much better performance.

Probably the best example of this is the Win32 api.  As you say, underneath its purely procedural, but it's amazing what you can achieve armed with SendMessage and the list of available paramaters.

Scintilla (used in Scite) is a good example that uses Win32 message passing to great effect.

http://www.scintilla.org/ScintillaUsage.html

You trade a rather clumsy syntax for a system that really shifts, but is still quiet clean at a conceptual level.

Ged Byrne
Saturday, May 03, 2003

Isn't the problem of generic message passing that message parameters are not strongly typed? An example is the SendMessage function mentioned above. I see object properties and methods as message passing primitives, but with strong typing.

Frederik Slijkerman
Saturday, May 03, 2003

'Messaging' (which implies asynch) might be the wrong word... really you seem to be talking about component architectures... and COM, CORBA, & especially dotNet probably aren't too far removed from what the folks were anticipating.

Pls expand a bit on how you see these 'objects' interoperating.  Objects are never going to organize themselves, or at least they're unlikely to organize themselves to do what you want!

Somehow or other you have to define the interfaces between your components... and if they're going to be tightly coupled & efficient then those definitions are intrinsically a bit ugly.

To my mind COM made some of this more complex than it really needed to be by trying to make it simpler than it could possibly be... in a perfect demonstration of Joel's Law of Leaky Abstractions they got themselves into huge trouble by pretending that inprocess, outofprocess, and networked components could be treated the same way in stituations where they couldn't. 

They may have done the same thing in reverse with dotNet... that is where COM was a good inprocess architecture sometimes pressed into a distributed framework, maybe dotNet is a good distributed architecture being pressed into a local components framework.

I also think COM would have been less ugly if Microsoft had come up with an extension of C or C++ earlier that incorporated the interface definition language more cleanly and chucked out the lousy obsolete old C/C++ header file based linkage model.  But I guess I'm getting a bit off-topic.

Mostly I'm just agreeing with Ged.  I've never used Smalltalk.

John Aitken
Saturday, May 03, 2003

Is SendMsg strongly typed or weakly typed?  I dunno... it's a battle of semantics (double entendre).  SendMsg() takes a handle to a window (clear enough), a message code (clear enough in one way but not another), and a wParam and an lParam (which could be almost anything depending on what the message is.  From a transport point of view they can all be treated as 32bit integers, to get to their meaning you need an SDK reference.  SendMsg is generic in one sense, but really a kludge to get over aforementioned linking problems.

dotNet might get much closer to the messaging ideal, because all it sends or recieves is a string, and that string could represent almost anything, and there is some potential to indicate the meaning of the content within the content.

So mostly I'm just babbling, but maybe I'm largely agreeing with Frederik too.

John Aitken
Saturday, May 03, 2003

John,

Theres an interesting discussion on whats wrong with COM and how it could be fixed here.  Don't know if you've read it before.

http://www.relisoft.com/win32/olerant.html

Ged Byrne
Saturday, May 03, 2003

Re: What's wrong with COM.

I'm no COM apologist, but that link above seems to make the hugely wrong assumption that COM only has to work for C/C++ objects. 

A lot of the quirks of COM are due not to bad design decisions, but the requirement that COM be usable from Visual Basic and similar higher level languages that may or may not have native support for things like true inheritence.

George McBay
Saturday, May 03, 2003

I thought people might get tangled up in thinking that COM and all its inheritors was some similar kind of messaging system as Smarttalk.

But it really isn't.  COM is a way of abstracting the problems of calling foreign objects, whether those objects are in application space, machine space or network space.  Its a negotiation about interfaces.

In the end though the called object is instantiated in some way, either directly or by a proxy.  Yes we could call the calls into that object messages, but they are one way messages with only a simple return.  Sharing data is a different problem.

In a message based system all objects can send messages and receive messages, and they may delegate messages to other objects.  There tends to be the same negotiation phase (what messages, what kind of data) but the process from there on is quite different.

The messaged object doesn't belong to the messenging object in quite the same way as within COM or the 'procedural' model of OOP.

Although its more likely that you would send a message to an object that you knew it could handle, its possible that the object could forward that message to some other object because either it didn't have the necessary ability or perhaps the necessary capacity.  But the abstraction remains, the originating messenging object knows nothing of that.

Eventually the goal of this could be that initially messages could be sent arbitrarily to objects with the best routes of those messages becoming learned (because the object which finally processed the message messaged the original object).

This is dynamic binding without the need of an object broker.  Its also a little bit more like the way life works.

Simon Lucy
Saturday, May 03, 2003

I read once about a system based on a technique simillar to the one you are describing. I don't remember what it was called, something with -bus. Software components could be added dynamically and all listened to the same bus, if they got a request that they could solve, they did it, otherwise they kept listening. I think the system where this was used was something huge like stock market system or airport system. Very flexible, since you could add and replace modules on-the-fly without modifying the others, and while the system continued to work.

So the technique you describe is alive and used. Just not so much for PCs. Why? Inertia could be one reason, but the other could be that the change in way of programming is quite huge, and while the technique has some clear advantages in large systems, these advantages may not be as important for let's say a word processor.

.Net and other component architectures are some form of half step towards this.

Anyone knowing the bus I'm talking about? I have a lapsus here.

Dimitri.
Saturday, May 03, 2003

Thanks for the link Ged.  I think the 'Insider' makes a very good point in observing that many of COM's difficulties stem from QueryInterface, AddRef & Release being IUnkown interface oriented rather than object oriented.

Still, I haven't thought through all the implications of his proposed improvement far enough to feel certain he hasn't overlooked something.

As for COM interoperability with other languages, hmmn...
Under the hood almost all the languages work the same way anyhow, or at least the way they work can be expressed well enough in C or C++ if you just observe certain conventions and constraints.

I'd have preffered that scripting language support had been implemented in a more separate translation layer, rather than by having IDispatch so closely tightly integrated.  I'd have similiarly preferred that proxy stub remote invocation be clearly dealt with as a separate though somewhat related issue, rather than leakily abstracted.

More loosely coupled messaging architectures can be and are built as extensions on top of COM and other interop standards, but using them exclusively would needlessly burden every component call with extra overhead, and throw away the contribution of a good compiler in helping validate definition against usage... ie. unless you came up with some alternative automated help debugging would become grevious.

John Aitken
Saturday, May 03, 2003

Dmitri,

What you're talking about I have seen referred to as the 'chalkboard' or 'whiteboard'. There's a section about it in "The Pragmatic Programmer'.

Tony Chang
Sunday, May 04, 2003

It probably also needs pointing out that Smalltalk has no way of defining data.  Instead even constants are objects.

So x = 2 + 3

would be sending the message Add to the object 2 with the parameter as object 3 and send the Value message to x


And if this seems an unnecessary and  performance hitting abstraction its also worth remembering that even constants have to be addressed somehow so inverting them from simple scalar values into members of the class Number (or Integer or whatever) perhaps isn't the hit it might first appear.  Given that its hidden by the grammar of the language.

Simon Lucy
Sunday, May 04, 2003

Dimitri : are you talking off sthing like Tibco's muticast messaging system maybe?

www.tibco.com

Frederic Faure
Sunday, May 04, 2003

The perfect thing of course would be a language or approach that allowed you both loose-ness when you want it, and tightness when you want it, with a minimum of scaffolding boilerplate code.  Maybe this is what 'attribute' based code can do?  Does C# fit the bill?

Agreed, sometimes you want to just broadcast notice of some event for the possible benefit of listeners you know little or nothing about in the most generic way.

Sometimes, on the other hand, I've seen cases that screamed out for extremely strongly typed languages... where I'd want my compiler to complain if a method were passed a velocity when it wanted an acceleration, or returned a window ID but I assigned it to a bitmap ID.

The way you describe the Smalltalk approach (which meshes with what I've heard elsewhere), it's kindof double extra super OO.  I can see how that approach can accomodate both looseness and strictness, but usually (at least in C++) the price is verbose and complicated class definitions.  In my strict case above, all I'd really want from, say a 'mass object' / variable is simple access to the undelying float... a typedef really, but one that the compiler could do dimensional analysis against.  C++ ish OO would unduly bloat / obscure the simple essence of many programs.  So, it's not just about performance, but also about clarity and conciseness.  Is Smalltalk any simpler / cleaner in this respect?

John Aitken
Sunday, May 04, 2003

COM provides at least one widely used pretty loose notification framework... in VB it uses a 'WithEvents' / 'RaiseEvent' syntax, underlying it is the 'IConnectionPoint' interface.  It can sometimes offer pretty cute sorts of extensibility, but can also lead to poor performance and real weirdness when mutually unaware 'listeners' each play with common public objects in a way the other didn't anticipate.

John Aitken
Sunday, May 04, 2003

Seemingly Eiffel is meant to be a kind of step between Smalltalk and a procedural language such as C++.

The syntactal coarseness of it though puts me off.  For instance there's no such thing as a For Next loop, you have to manufacture one out of an Until loop with a hand coded increment.

On the other hand it does treat numbers as members of the class Integer and the only way you can assign values in another object is to use getter and setter messages.

Simon Lucy
Sunday, May 04, 2003

Objective-C is an object-oriented variant of C that uses Smalltalk-style messaging to implement its object system.

Objective-C was the language used by NeXT in the NEXTSTEP frameworks, and as a result is the native language of the Cocoa frameworks in Mac OS X.  As a result, its popularity has increased pretty significantly.

The overhead of dynamic dispatch really isn't significant for most uses, and you can always either drop down to C or C++ when you need extra speed.  And between dynamic dispatch and a full runtime, you can write software a lot faster than in other environments.

NeXT bought the rights to the Objective-C language back in the 1990s.  The official definition is "The Objective-C Programming Language" at the following URL: http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/index.html

Objective-C can be used anywhere GCC is available, because a compiler is part of the GNU Compiler Collection.  GNUstep, an Open Source implementation of OpenStep (Cocoa's predecessor) also runs on a wide variety of platforms, including both Linux and Windows.  (Though its Windows support probably isn't as "done" as its Linux support.)  http://www.gnustep.org/

Chris Hanson
Sunday, May 04, 2003

Chris,

I agree with you as i was about to psot what you just said.

Apple uses the gcc compiler and it is able to mix Objective C, C and C++ all together, even in the same file (when that happens, they call it Objective C++).

Objective C really is very similar to Smalltalk, but is a huge improvement I think because of the way it can compile and link with C and C++ code.

Ed the Millwright
Monday, May 05, 2003

*  Recent Topics

*  Fog Creek Home