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