On Jun 27, 2012; 4:27pm, Stephane Ducasse wrote:
On Jun 27, 2012, at 4:44 PM, James Foster wrote:
Stef,
I'm sorry to hear about your burnout and I understand that you are not prepared to seriously discuss the issues that others have raised. I hope when the issue is raised again (it does seem to come up every year or so!) we can correct some of the misunderstandings that exist.
yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. Now for 20 we should finish all the open tracks we have.
Stef
Hi, A comment from a complete outsider: I've been following pharo on the side for the last year or so and am very impressed by both smalltalk as a language and pharo as an implementation. I am not trying to even voice an opinion of what's right to focus on for pharo project since that's not my place having nothing invested in it (so far, gearing up to add some pharo parts to my world). It did strike me that it could be interesting to hear the view from an outsider on what would draw interest and more users/developers to the project. Be it inspiration for pharo 2.1 or 3.0 or 4.0 :) I'll first state a belief: I believe that the explosive growth of ruby and python communities to some extent depended on good package management systems making it very easy for people to publish/share/collaborate on packages. A killer app to kick it off, but one needs easy collaboration to grow. On the back of that I'm very excited to see the following pharo efforts being close to coming together into something great: 1. Stripped down core kernel and bootstrap project 2. Fuel for fast serialization and deserialization (can be used for binary packages) 3. FileTree 4. Metacello scripting API 5. Metacella Git/Github integration 6. Tools such as Versionner on top of Metacello for ease of use 7. Namespaces/Environments In terms of getting a lot of people much more comfortable diving into the image world I think that list have great promise. If one can easily start with a minimal kernel, have some simple tooling such that one from e.g. the commandline can bootstrap it via Metacello configurations that pulls in both the parts of the base system one needs and project/application dependencies to get a working image for both development and deployment (via metacello groups for example) it has 2 benefits: 1. Reproducible process which means automation and testing a lot easier for projects (jenkins etc for applications), as well as deployment 2. It's a workflow that's quite similar to how one would for example work with ruby, rubygems and bundler (on a high level). Familiarity draws in more people - it shouldn't be at the cost of a good system, but if one can get both it's a definite positive. Once project/appliation bootstrapped like that and one is working in the image tools like Versionner and Metacello with git/github intregration will provide an excellent workflow for collaboration (push/pull/merge/branch/etc). Again I see 2 benefits: 1. Functionally solid (see e.g. the Practical Git for Smalltalk presentation by Dale) 2. It's familiar to outsiders and has a good chance of attracting new people. Even if one has great in image tooling it's very good to be able to be a "lazy" follower of a package/project via e.g. github (RSS feeds for changes, nice diffs accessible from any web browser, pull requests, graphical representation of branches etc etc). I for example would be much more likely to have learnt more on pharo implementation if I could have followed it on github for the last year. When collaboration increases and people share a lot of packages via e.g. git & github one tend to see exponential reuse and number of new packages created (on the back of what exists), and at least the ruby experience is the average number of package dependencies for a project increases. It's in that point of view I'm seeing namespaces/environments as an important addition. Prefixing names is doable and at a non-human level you can accomplish most of the same things, but on a human level I see it as important - and it gets more important the more collaboration and reuse of existing packages one accomplishes. A non-technical consideration is that developers these days kind of expects some form of namespacing to exist and not seeing it available is something to deter some possible adopters (rightly or wrongly, many times they wouldn't need namespaces/environments, but many may not reflect too deeply on that). I know I twigged at first seeing prefixing being used instead of some form of namespaces.
From that this perspective (namespaces/environments more important as more people are, reuse and collaboration happens) it seems quite sensible to put it after the other things on the todo list (as long as it doesn't goes away completely).
Hopefully that's of some interest :) I'll continue my journey towards using pharo more - we shall see how it works out for me! Regards, Patrik -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4639158.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.