On Mon, Mar 02, 2009 at 11:46:47AM +0000, Keith Hodges wrote:
I believe you are correct, but not everybody sees Pharo that way. Edgar and Keith in particular, sometimes see it as non-appreciation of their work, which is similar in spirit, but not as well managed.
Matthew,
My response to pharo is based upon the ironic situation.
I say for 3.11 "Lets promote a process to enable integration and sharing of the contributions of the community, accross the diverse range of images that we use" Pharo team says "Lets go off and do our own thing", and Edgar says the same. I find this totally ironic and sad, since you couldn't create more fragmentation of the main squeak protagonists if you tried.
Well, for one thing, our tools were not ready for mainstream use when Pharo/Sapphire was announced. From what I can tell, the tools are just now coming to that point. We cannot expect that everybody will stop what they are doing just to alpha-test our tools. If they do, great, but if not, don't be mellow over it.
Now of course the whole point of the tools we have been working on, for 3.11 Bob etc, is to allow diversification, so we should welcome all of pharos efforts and innovations, and any like it. You seem puzzled as to why I don't appreciate pharo.
Do you appreciate Pharo?
The problem arises when no-sharing is done of the fundamental components that make the sharing possible. For example SUnit needs to be a common piece. It has to be there is no option. So if you do a fork and within your fork you fork your own version of SUnit, you are snubbing the rest of the community, and any possibility of working with the rest of the community, either by ignorance or on purpose.
Not everything needs to be "for the community". If we insist that it be so, we lose developers due to restrictive policy. It is more important that those who are good at fixing code (Pharo) do so, and leave the "giving it back to the community" to those who really care about it, like you and me. Pharo is providing a valuable service as a test-bed for new ideas and things that are not backward compatible. We will be providing a service to bring more commonality to the community. Both are important, and neither should halt on behalf of the other.
This has to be a managed policy decision, from the top. It is precisely because the pharo project is not managed and planned with any such principles in mind, that I stress my point, and will continue to do so.
The lack of such concern is a good thing.
In reference to recent discussions about Preferences how am I going to write any common code between pharo and squeak, if the preferences api is different, between squeak and pharo? Note that the tools and preference system can be as different as you like, but the API has to be common at some level for any sharing to be possible. We either keep the same api we have, or design a new one, and provide a basic specification that can be implemented in both environments.
Or, put both in for a release or two, where the old is deprecated, then remove the old after a release or two.
What we cant accept is any proposals or discussion about such an important API without appreciating that it will be expected to support code that comes from both environments.
Such a restrictive policy is the best way to ensure that nothing will ever change, and that somebody will fork to get away from such management overhead.
The fact that 'Author' exists only as a global in the Pharo environment and prevents code which uses it from loading in squeak is all the proof I need that the pharo process needs a rethink.
It can be backported, or ported in full, if it is a win. Traits are a win, and we backported them to 3.8 for Monticello 1.5. I don't see why we can't do that again. We can provide the service of backporting good ideas to other distributions. It will be easier when Pharo adopts Bob to some degree, but nothing prevents us from doing it now. There is a reason that Linux distributions are made of packages that are not maintained by the original coders, and that is because distribution of packages takes time. If somebody is better at coding, they should code. If somebody is better at packaging, they should package. Specialization is a good thing; everybody is more productive in the end, and has more fun, because each one is adding value while doing what they love. Always have fun. If you have fun on Pharo, than do Pharo. If you have fun on tools, then do tools. There are enough people in the world that somebody will have fun working with both, and will bridge whatever gap has formed. I believe I am such a person. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/