On Tue, Feb 12, 2008 at 08:59:46PM -0800, Geoffrey Broadwell wrote:
> Here's my fear:  Parrot will near production release, we'll start
> finding performance problems, and everyone will be so incredibly ready
> to get 1.0 out the door that we'll release before fixing them ("correct
> now, fast later" and all that).  Unfortunately, we'll find out after the
> release that the only way to fix the performance problems is to make
> some deeply incompatible change, and suddenly we'll be staring down the
> barrel of the production release compatibility shotgun.
> 
> I dunno how likely that is -- fears are irrational beasts after all --
> but there it is.

FWIW, I'm not too fearful of this particular scenario coming to pass.
At the moment there are sufficient layers of abstraction (some might
say "too many") that if we do discover a deep change is needed, I think
we'll be able to adjust the various intermediate layers to keep it
from significantly affecting production-release level items.  At the
very least, compilers and translators built using the compiler tools
shouldn't see significant structural changes due to changes in Parrot
internals, unless the compilers are using lots of inlined PIR and/or
making some big assumptions about Parrot internals.  (And even for
those compilers that are making such assumptions, I still think
we'd be able to manage it.)

Pm

Reply via email to