From: MikkelFJ <mikkelfj-anti-spam@...>
Date: 2002-12-19T06:51:49+09:00
Subject: Re: help -- persuade my boss to adopt ruby


"Dan Sugalski" <dan@sidhe.org> wrote in message
news:a05200f1cba2657db1f13@[63.120.19.221]...

> >dynamic typing can coexist with static typing in one program
>
> It doesn't get you any of the benefits you wanted it for, though.
> There's no speed win without a lot of work and there's no safety win.
> What, then, is the point?

Doesn't Dylan do this quite convincingly.
Of course it always turns out the way you don't bother with static typing -
as I recall the Dylan hackers a ICFP contest never got around to really
optimize the code. The idea was to prototype quickly and then optimize the
critical bits.
As an alternatively to moving to another langauge it is quite compelling.

> >DS> Partial typing is of no use for speedups. The only way to get an easy
> >DS> speedup is to go fully-typed and forbid runtime method redefinition.

I'm not sure this is true: By using more space you can have a default
implementation and a fast implementation. Quite often the method is not
dynamically modified - the trick is to quickly detect which version to use.
And it as non-trivial to do compiler inlining - therefore you need very fast
function calls.

I imagine a bytecode executable where each method registers the code
locations where it is referenced and updates them if modified. Or methods
are called with an extra indirection (vtable style) so the update is only
done in a single place.

This approach completely gets around freezing or prohibiting modifications.
It's fast as long as nobody fiddles. Thus end-programmer optimization would
not be to freeze code, but to avoid modifying context where not necessary.
I.e. you can trade flexibility for speed simply by the programming style.

Mikkel