> > 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. 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. 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. 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. It took me 25 years to understand that I had been hacking code for 25 years! I did a large test driven project, following some XP principles, and realised that it is possible to plan, and to release professionally developed code. I know the difference between hacked up code and a planned managed process. To be honest I prefer the hacking approach for first iterations, and most of my squeak work has been hacked up due to time constraints. Rio, planned as a replacement for FileDirectory is now two years old! It is managed by tests, and reached perhaps 70% of the way there just this weekend, in terms of professionality. The current 170+ tests should be reviewed, code coverage and feature coverage checked, and the regression suite needs to be run automated on at least three platforms. I am saying that it takes a lot of effort to make a new module without hacking, and that module once defined should be potentially adoptable by all Smalltalks. (Rio is a bit squeak specific at present). 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. 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. 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. cheers Keith _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
