Could Python supplant Java?

[Paul Foley]

On Wed, 21 Aug 2002 06:22:24 -0700, James J Besemer wrote:

> Some more zealous sources claim that "polymorphism" and other OOP
> techniques are impossible with early binding and thus require late
> binding to make it possible.  This is bullshit.

Assuming the "this" that you say is bullshit is not self-referential
(like "this statement is false"), please explain how it can be done.
In /some/ cases enough information may be available at compile time
that the compiler knows what will be called at that run-time, in which
case it can produce the appropriate code at that time (early binding),
but that's not usually the case, and the binding must be delayed until
run-time (late binding) if you want the code to function correctly.

E.g., if you have two classes, A and B, where B is a subclass of A,
both of which implement a method bar(), and you have a function/method
like (using C++ syntax, without implying C++ language)

  SomeType foo(A x)
  {
      ...
      x.bar(...);
      ...
  }

there is no way the compiler can tell at compile time whether x.bar is
going to be A.bar or B.bar at run-time -- it depends on the caller!
To work, it needs to dispatch somehow off the run-time type of x --
that is, late binding.  [Obviously, if all callers are known at
compile time, the compiler can potentially tell whether all calls will
go to the same place, so by telling the compiler that it won't be
called from outside that compilation unit (by declaring it "static",
in C++) you may be able to avoid the run-time dispatch, if you don't
need to call it from anywhere else]

If you had

  SomeType foo(B x)
  {
      ...
      x.bar(...);
      ...
  }

and had told it that there were guaranteed to be no subclasses of B
(or that they wouldn't define their own versions of bar), the call
could be compiled early.  (Dylan calls this "sealing"; but C++ has no
analogue...unless it's grown one in the years since I last used
C++...)

> However, saying both systems are "strong" suggests a near-equivlance
> when in fact the semantics and implications for developers are
> rather different.

Hence the static/dynamic distinction.

> Thus, true Pythonistas will argue that late binding (by any other
> name) is superior.

Early binding is clearly superior -- but too-early binding is not, and
compile-time is often too early.  [Hence the proliferation of "times"
in Lisp: you can have things happen at at least five distinct times:
read time, macroexpansion time, compile time, load time and run time;
and I suppose you could prefix design time and write time to those]

During development, compile-time is almost guaranteed to be too early.

To paraphrase someone (Einstein?): Everything should be done as early
as possible, but no earlier.

-- 
For þæm se þe his cræft forlætt, se bið fram þæm cræfte forlæten.
                                                                -- Ælfric
(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))