Hi eliot we are nearly in sync :).
> and e.g. if it looses traits then at least provides tools for importing > packages with traits, eliminating the trait usage on the way in, and in > general provides tools for cleaning-up packages (i.e. refactoring with > clean-ups) so that old packages continue to function, and so that users can > continue to use Pharo in their daily work. We always pay attention to that. We are working on tools to support change and evolution. Now we do not have enough man power. Torch is the example of the best tools for understanding changes I have seen but this is > But you also need Pharo the Phuture, which is a system moving towards your > vision. By maintaining the two side-by-side you get to work on migration > tools and you keep the existing user base happy while helping people to dip > their toes in the Phuture water. I know its expensive, yes we know that and this is what we are doing > but if you just provide Phuture you'll alienate the existing user base and > you won't provide a well-tooled migration path to bring that user base into > the future. This is an agile, incremental approach to getting the entire > community into the future, oh yes that we know and this is for the reason that classboxes were not adequate for real usage that we never push them. > instead of an isolated incremental approach, where only the developers at the > core of Pharo can keep up with the incremental progress towards the vision. > Anyway, that's how I would go about it. Yes this is our vision and process too. eliot what I want to say is that we did pharo to open space and reinvent Smalltalk. I have no problem to perform a real analysis and decide that we made a mistake and learn from it with traits (see the beginning of the other mails). I have a problem with cries and backward compatibility for the sake of it. If one of the smalltalk adds a good feature then we should copy it and we should add what we think is important. Smalltalk is not carved in stone. This is what we did for pragma (they are cool). We have the initialize invoked automatically (like CLOS since 90). Now if we do not give intellectual space for inventing on the pretext of backward compatibility then frankly better do something else. I think that pharo is doing a good job and we will continue and we will add/change the language for the better. We want slots for example because this is really good. And some people will do not like it and be against and use the "non compatible" flag. The feedback we got from some venture oriented people is that: it is old. Sure they are probably idiot but with money and power in our case. So if I would sell the java, javascript it would be much simpler (even if the java hype i over and people are open to dynamic language): clojure, scala... xxxx. So my point is at least we should be imaginative and show that we are smart and that we can learn from others and be open to change. This is my main point. I do not care about traits: I care about innovation and the place we give it. For example we got a really nice presentation from tom van cutsem about the new scheme for proxy in Javascript and this is good and they will have a nice way to secure some part of Javascript. So mariano is working on Ghost and we want a really good proxy implementation and we will have it. This is the same for Fuel: we liked the idea of the pickle format and we will have a nice object-serializers. These two examples are not about the languages but for me this is the same. Ghost is based on a VM hook that does not exist in other Smalltalk. so too bad ;) Stef
