[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the forward method [dynamic vs. static typing]
On Nov 25, 2003, at 11:55 PM, Anton van Straaten wrote:
>> 1. forwarding is a very flexible and powerful mechanism
> For what purposes? You haven't made any case for it yet.
Ah, every conversation I've ever had with a ST-er has always involved
them scratching their head at some point and saying "but why would you
want to do that?". :-) I'd suggest looking into how much easier it is
to implement distributed objects in a language with forwarding. Either
the language supports it, or you end up implementing a runtime on top
of the language that supports it (which is a big mess). Which reminds
me of Greenspun's Tenth Rule of Programming:
"any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Which in our case might be:
"any sufficiently complicated program written in a static system
contains an ad hoc informally-specified bug-ridden slow implementation
of half of a dynamic system"
>> 2. you agree that a type system is useless with forwarding
> it's possible to have
> certain kinds of objects which support forwarding and others which
> In previous posts, I described approaches in languages like C++ that
> actually do that sort of thing in practice.
Are you saying C++ supports forwarding? Btw, I don't mean "can it be
implemented?". This isn't a question of Turing completeness. The
question is if it's a natural part of the language. For example, C++
doesn't even compile the method names into the executable, so
forwarding is impossible at the level of native C++ message calls.
> In a higher-level language than C++, static type analysis could be
> used to
> detect messages that are likely to need to be handled by forwarding,
> and an
> IDE could flag them as such, perhaps with a color. For example, the
> DrScheme IDE flags undefined variables in red, even though Scheme is
> sufficiently dynamic that it cannot normally be sure that a variable is
> undefined until it is accessed at runtime. This can help a developer
> issues while editing code, and decide whether any action needs to be
> What's the downside here? Is it (a) impossible, (b) not important,
> (c) too
> ambitious for insufficient payoff, (d) other?
The more dynamic the system, the fewer assumptions you can make at
compile time and the less useful compile-time checks become. (for
example, in systems where any object can forward messages, all compile
time bets are off)
The more static the system, the more assumptions you can make at
compile time and the more useful compile-time checks become.
So the two are a bit at odds. Now the problem for real-world
programming is how to build good systems quickly and easily. Does the
ideal system lean heavily or completely toward static or dynamic
systems or off in some other direction entirely?
If it's extremely dynamic, then your (a) is true. If it's heavily
dynamic, then your (b) and/or (c) is true. If the ideal is off in some
other direction then your (d) is true.
Without good empirical data, we don't know what the ideal system is so
doesn't seem prudent to dismiss either position (even in it's extreme)
as simply the result of ignorance or capriciousness (as was done in the
post that started this thread).
Btw, I'm not entirely against the notion of any form of type checking.
I just suspect that the ideal system is highly dynamic and so ST is
unlikely to contribute enough to be worth focusing on at this point.
I'd guess the reason it's still given so much attention has to do with
the fact that historically, weakly typed systems preceded strongly
typed ones. Static typing is extremely useful in weakly typed systems
as a type error that writes on the wrong memory can result in very
difficult to trace bugs. It seems to be unconsciously assumed that this
value extends to strongly typed systems despite the fact that strong
typing eliminates this class of problems.