Hacker News Reader

Comment by cconroy | Hacker News Reader

What does Kay mean by late-binding? ... not the dynamic binding of overriding methods in a subclass or virtual functions (C++)? The last paragraphs compared smalltalk with lisp in this respect.

View on HN

Not being in his head, I'll try to guess from what I know of smalltalk. It means the actual binding of a message to the method to execute is done only when the message is received. TOo give you an idea, you may associate some code to specific messages to an object at runtime, you may also implement doesNotUnderstand and decide how to handle messages who don't have corresponding methods (forward it to another object, have some special behavior, create the method on the fly as needed).

  Foo.counter = 0;
  Foo.prototype.handle = function(message, data) {
    if (message == 'bar' && Foo.counter < 3) {
       return this.bar(data)
    }
    else {
      throw "I forgot about 'bar'."
    }
    Foo.counter++;
  }

Not too sure about what the point is, or maybe it is just my limited knowledge of javascirpt that's playing me tricks. In any case I didn't know of a prototype.handle function and can't figure out any way for it to intervene in the usual way of calling functions on an object.

var f=new Foo()

f.bar() //Just says that f.bar is undefined and therefor not a function

//If I add

f.bar=function(something){return "nothing"}

//Calling

f.bar("ABC") //Many times always answers "nothing"

There isn't such a function built-in, though something like it (a doNotUnderstand functionality to call a default function instead of throwing an error if the requested field isn't found on an object) has been proposed as a future addition to the JavaScript standard.

IgorPartola's example code won't intervene in the usual function-call process; rather, it provides a tacked-on means of simulating message sending behavior that ought to be included in the language's syntax under Kay's definition of OO. With this convention, you'd never call bar(), or any other method, directly; you'd call handle to send a 'bar' message to the object instead. Then, if you send a message the object doesn't understand, handle() can route it properly.

Lua has this, with metatables that can set methods to handle undefined stuff. It is actually very useful and you can do a lot with it.

Based on his references to biology and cell signaling as inspirations, I think you're on the money.

Possibly the full dynamic dispatch (AKA multi-methods) that you get with systems like CLOS - where the types of all of the arguments are used to compute matching methods, not just the type of the object you are invoking the method on.

http://c2.com/cgi/wiki?SmalltalkLateBinding

I think he does mean runtime binding, as with a virtual function call. But probably more extreme - instead of a lookup table to find the static type, a message is simply sent to the receiving object. The object itself then handles it based on its type definition (which itself could be defined at runtime).

And the object can handle messages for which no function exists at all.

This (#doesNotUnderstand:) is not very widely known but extremely important:

http://carcaddar.blogspot.com/2009/04/closure-oriented-metap...

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

Binding time was thought of as compile time, link time, runtime, and even execution time. So in the time frame he was talking about nearly everyting had early binding, compile time or link time when libraries were included. With todays languages, like Java you have runtime loading which would be considered late time binding. Dynamic languages like Python have extremely late binding where the operator/operand type binding is done at the operator execution time.

C++ virtual functions are close but it would have to have a method missing construct before it would meet his full definition.

It means when you have a name for something, the association between the name and the thing should be done as late as possible. In the case of a method call, the method to be invoked for a given message name should take place at the time of the call.

I've a lot of respect for Dr. Kay, but history has shown him to be wrong on this point: strong static typing and binding things as early as possible is how robust systems are built and how errors are minimized.

However I won't doubt that the Smalltalk approach is probably right for its original intended purpose (exploratory or didactic programming).

> strong static typing and binding things as early as possible is how robust systems are built and how errors are minimized.

Huh? What about Erlang?

Erlang is very good at making systems that can sort of muddle along and keep running despite containing serious mistakes, but it's almost no help with preventing or fixing them. Every static type (even inferred) does the work of a number of unit tests, though of course not all.

I suppose you've never head of Dialyzer which gives much better coverage than most static type systems.

No I had not. If Erlang now has working type checking, that's a huge advance. But I have to wonder why the Wikipedia page still claims Erlang is dynamically typed and doesn't mention this, and the getting-started guide barely names Dialyzer and doesn't demonstrate it at all (instead it's somewhere in the middle of the FAQ). How much consensus is there that it's ready for prime time?

The fact that you can analyze the types doesn't necessarily change the fact that the language is dynamically typed (accepting that the terms are kind of wavy to begin with, and I've heard people mistakenly apply the D-word to very strongly statically typed languages with type inference).

It's still dynamically typed. The dialyzer ("discrepancy analyzer") can detect many kinds of type errors statically by doing dataflow analysis over the possible types yielded by successful execution, but it's an external tool. Like lint, not part of the core language.

For a good overview, check "Gradual Typing of Erlang Programs: A Wrangler Experience " (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.160....) and/or "Practical type inference based on success typings" (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.62....).

> I've a lot of respect for Dr. Kay, but history has shown him to be wrong on this point: strong static typing and binding things as early as possible is how robust systems are built and how errors are minimized.

Could you expand on this? I don't see how late binding is incompatible with the robustness that static typing provides. In a traditional (C/++/#/Java) OOP setting, virtual methods and dynamic method dispatch allow for late-binding of method names to behavior based on run-time type specializations, but you still have the static compile-time guarantee that a method with the appropriate name and type signature will exist. This seems to me like it has the same robustness as an early-bound model, bounded only by the sophistication of the type system. Do you consider it qualitatively less late-bound than the message-passing paradigm, or am I missing something?

Reply on news.ycombinator.com