Another really important point about pharo. We want to make sure that the system as a whole can CHANGE and EVOLVE. Of course change is costly because it can impact others but this is really important if we do not accept change there is no way that the system can get better. A good system is like simCity and not like a stack of stuff added one on top of the others. Then we want pharo to be the vehicule to invent new systems. We want pharo to make sure that Smalltalkers can build great abstractions which are the strength of the language. We would like to have better support for creating new languages, systems.... A concrete example, we would like to have first class instance variables instead of plain string (The benefits are really important - I will not explain that here). But if you look at Tweak (at one point) the class definition got added XML specification to have different instance variable kinds: We do want XML for that since it can be done in Smalltalk and also we do not want to patch the compiler just for that but we would like to have first class instance variable with a nice protocol to be able to specify different instance variable semantics. Of course it will take time because we want to pay attention not to break .... and we should find the time to do it. In pharo - we do not accept anymore to see a bad method and close our eyes (ref to pragmatic programmers book and the story about the broken window - the point is that if you walk in a street with dirt everywhere, papers on the floor and you leave in a house with one broken window, may be you will throw away paper on the floor and probably you will care when the next window will be broken. We want a system where there is no dirt on the floor (or controlled) and broken windows got repaired as soon as they appear) - we do not accept not to integrate a good fix because it may break an old experiment nobody maintain anymore. Also the fact to have a leaner system will make sure that we can maintain it adapt it ... test it, document more easily. Stef