[Pharo-project] Pharo is exploding
it was a time, when were able to track all activities around squeak, pharo and vm.. today the amount of updates, news and activities is just overwhelming.. a rusty locomotive, which once staying in backyard, repaired by Stef and Marcus and now goes faster and faster :) -- Best regards, Igor Stasenko.
On 15 May 2012, at 04:43, Igor Stasenko wrote:
it was a time, when were able to track all activities around squeak, pharo and vm..
today the amount of updates, news and activities is just overwhelming..
a rusty locomotive, which once staying in backyard, repaired by Stef and Marcus and now goes faster and faster :)
So true: I am happy and frustrated at the same time. So much is happening, I can't even follow all the stuff that falls into my own domain, let alone all the other interesting things. Sven
A random thought: how about a stackexchange site for smalltalk? Most of the things disussed on the list could probably go there and the list would once again be a quiet place for core stuff only. We (or I) would have to propose a new site and we would need people from Pharo AND Squeak (and hopefully other dialects too) to come aboard to promote the site. The entire process of creation is explained here: http://area51.stackexchange.com/faq Cheers, Max On 15.05.2012, at 07:30, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 15 May 2012, at 04:43, Igor Stasenko wrote:
it was a time, when were able to track all activities around squeak, pharo and vm..
today the amount of updates, news and activities is just overwhelming..
a rusty locomotive, which once staying in backyard, repaired by Stef and Marcus and now goes faster and faster :)
So true: I am happy and frustrated at the same time. So much is happening, I can't even follow all the stuff that falls into my own domain, let alone all the other interesting things.
Sven
Hi, I don't believe a site for all smalltalks would be good at all. Reason is that they are very different and generates tons of different answers (increasing our difficulty to keep track of what is happening, who needs help, etc.)... Even related smalltalks like Pharo and Squeak are diverging really fast, and is becoming harder to have same answer applying to both (of course this is not 100% true, and still there are things that fits both words) One exclusive for Pharo, on the other hand, could be a great addition :) best, Esteban On May 15, 2012, at 7:46 AM, Max Leske wrote:
A random thought: how about a stackexchange site for smalltalk? Most of the things disussed on the list could probably go there and the list would once again be a quiet place for core stuff only.
We (or I) would have to propose a new site and we would need people from Pharo AND Squeak (and hopefully other dialects too) to come aboard to promote the site. The entire process of creation is explained here: http://area51.stackexchange.com/faq
Cheers, Max
On 15.05.2012, at 07:30, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 15 May 2012, at 04:43, Igor Stasenko wrote:
it was a time, when were able to track all activities around squeak, pharo and vm..
today the amount of updates, news and activities is just overwhelming..
a rusty locomotive, which once staying in backyard, repaired by Stef and Marcus and now goes faster and faster :)
So true: I am happy and frustrated at the same time. So much is happening, I can't even follow all the stuff that falls into my own domain, let alone all the other interesting things.
Sven
On Tue, May 15, 2012 at 4:43 AM, Igor Stasenko <siguctua@gmail.com> wrote:
it was a time, when were able to track all activities around squeak, pharo and vm..
today the amount of updates, news and activities is just overwhelming..
a rusty locomotive, which once staying in backyard, repaired by Stef and Marcus and now goes faster and faster :)
I think we have to improve the foreknowledge about what will happen, why it will happen, what it will mean, what are the related issues etc. I in most cases I have no clue about changes in package structure of the image that are being performed and that require changes in Pharo Kernel processing, initialization etc. As an example I can mention recent CodeImporter integration. I like the improvements rate but as the side effect it makes Pharo less attractive platform for serious development. -- Pavel
-- Best regards, Igor Stasenko.
On Tue, May 15, 2012 at 9:40 AM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
On Tue, May 15, 2012 at 4:43 AM, Igor Stasenko <siguctua@gmail.com> wrote:
it was a time, when were able to track all activities around squeak, pharo and vm..
today the amount of updates, news and activities is just overwhelming..
a rusty locomotive, which once staying in backyard, repaired by Stef and Marcus and now goes faster and faster :)
I think we have to improve the foreknowledge about what will happen, why it will happen, what it will mean, what are the related issues etc. I in most cases I have no clue about changes in package structure of the image that are being performed and that require changes in Pharo Kernel processing, initialization etc. As an example I can mention recent CodeImporter integration.
I like the improvements rate but as the side effect it makes Pharo less attractive platform for serious development.
It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do seriuous development you won't beusing Pharo 2.0, will you? ;)
-- Pavel
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
On Tue, May 15, 2012 at 9:46 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, May 15, 2012 at 9:40 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Tue, May 15, 2012 at 4:43 AM, Igor Stasenko <siguctua@gmail.com> wrote:
it was a time, when were able to track all activities around squeak, pharo and vm..
today the amount of updates, news and activities is just overwhelming..
a rusty locomotive, which once staying in backyard, repaired by Stef and Marcus and now goes faster and faster :)
I think we have to improve the foreknowledge about what will happen, why it will happen, what it will mean, what are the related issues etc. I in most cases I have no clue about changes in package structure of the image that are being performed and that require changes in Pharo Kernel processing, initialization etc. As an example I can mention recent CodeImporter integration.
I like the improvements rate but as the side effect it makes Pharo less attractive platform for serious development.
It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do seriuous development you won't beusing Pharo 2.0, will you? ;)
I talked about that few days ago with Germán. The problem is not in using of unstable version. The problem is that it is very easy to stop to be in touch with Pharo now and within one year when the current unstable version will become stable the developers will face to very different system. That is one of the reason why Germán choose Cuis for his current projects. Developers want simple predictable system. I do not think that the way out from this is to slow down. On the contrary. We simply have to do this era of a lot of big changes as short as possible ;-) -- Pavel
-- Pavel
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do seriuous development you won't beusing Pharo 2.0, will you? ;)
I talked about that few days ago with Germán. The problem is not in using of unstable version. The problem is that it is very easy to stop to be in touch with Pharo now and within one year when the current unstable version will become stable the developers will face to very different system. That is one of the reason why Germán choose Cuis for his current projects. Developers want simple predictable system.
Absolutely wonderful. So what people wants just the same. Ok but this is not Pharo. And and and again again again and again who is concerned by RPackage vs PackageInfo, systemNotifier vs. announcement, better monticello, better canvas, better Zincâ¦. I find that a totally false argument.
I do not think that the way out from this is to slow down. On the contrary. We simply have to do this era of a lot of big changes as short as possible ;-)
On Tue, May 15, 2012 at 11:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do seriuous development you won't beusing Pharo 2.0, will you? ;)
I talked about that few days ago with Germán. The problem is not in using of unstable version. The problem is that it is very easy to stop to be in touch with Pharo now and within one year when the current unstable version will become stable the developers will face to very different system. That is one of the reason why Germán choose Cuis for his current projects. Developers want simple predictable system.
Absolutely wonderful. So what people wants just the same. Ok but this is not Pharo. And and and again again again and again who is concerned by RPackage vs PackageInfo, systemNotifier vs. announcement, better monticello, better canvas, better Zincâ¦. I find that a totally false argument.
I will quote Germán (I hope he will not mind): "lot and lot of things... Lot of new things each day. Not time to stabilize nothing. Is needed such acceleration? ... My point is, I'm trying to move a business with Smalltalk and the acceleration of Pharo is well know by me (from other companies) and sooner or later, impact in my job and I'm a very LITTLE software house can't migrate my products all the time." We simply have to accept that some developers can have this feelings and try to find a way how to limit it. I think that some official Pharo blog (maybe written by Esteban) would be very helpful. Some kind of not very extensive technical information source that will help people to stay in touch with Pharo progress. That will explain what is being changed in Pharo and why. I think that developers than will see the changes like positive not as alien ones. -- Pavel
I do not think that the way out from this is to slow down. On the contrary. We simply have to do this era of a lot of big changes as short as possible ;-)
Good balance between innovating/improving/changing and long-term confidence/stability/reliability is needed for a commercial tool. And both Germán and Marcus are right, both in their own way. I'd certainly like for Pharo to progress further but on the other side I'd like to get a better confidence on it. This is as said always a balancing act and yes, better communication of new release's merits and changes would help here. For us "outsiders", that is, Pharo users and not internal developers, for us a long list of closed issues means just nothing. Release notes kind of Gemstone has [1] would be better. Here main changes are explained in more detail. Also blog posts like Mariano's and Esteban's are very valuable as well. [1] http://community.gemstone.com/download/attachments/6816350/GS64-ReleaseNotes... Best regards Janko Dne 16. 05. 2012 09:23, piše Pavel Krivanek:
On Tue, May 15, 2012 at 11:29 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do seriuous development you won't beusing Pharo 2.0, will you? ;)
I talked about that few days ago with Germán. The problem is not in using of unstable version. The problem is that it is very easy to stop to be in touch with Pharo now and within one year when the current unstable version will become stable the developers will face to very different system. That is one of the reason why Germán choose Cuis for his current projects. Developers want simple predictable system.
Absolutely wonderful. So what people wants just the same. Ok but this is not Pharo. And and and again again again and again who is concerned by RPackage vs PackageInfo, systemNotifier vs. announcement, better monticello, better canvas, better Zincâ¦. I find that a totally false argument.
I will quote Germán (I hope he will not mind): "lot and lot of things... Lot of new things each day. Not time to stabilize nothing. Is needed such acceleration? ... My point is, I'm trying to move a business with Smalltalk and the acceleration of Pharo is well know by me (from other companies) and sooner or later, impact in my job and I'm a very LITTLE software house can't migrate my products all the time."
We simply have to accept that some developers can have this feelings and try to find a way how to limit it. I think that some official Pharo blog (maybe written by Esteban) would be very helpful. Some kind of not very extensive technical information source that will help people to stay in touch with Pharo progress. That will explain what is being changed in Pharo and why. I think that developers than will see the changes like positive not as alien ones.
-- Pavel
I do not think that the way out from this is to slow down. On the contrary. We simply have to do this era of a lot of big changes as short as possible ;-)
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Hi, On May 16, 2012, at 9:23 AM, Pavel Krivanek wrote:
On Tue, May 15, 2012 at 11:29 PM, Stéphane Ducasse
I will quote Germán (I hope he will not mind): "lot and lot of things... Lot of new things each day. Not time to stabilize nothing. Is needed such acceleration? ... My point is, I'm trying to move a business with Smalltalk and the acceleration of Pharo is well know by me (from other companies) and sooner or later, impact in my job and I'm a very LITTLE software house can't migrate my products all the time."
well... as you quote German, I will quote myself answering Germán (well... also translating from spanish and putting some context) :) I said something like: "No no no, that's not true" :) 99% of the changes affects infrastructure and/or replace old tools. Why your work should be affected by that? I migrated Seaside from 1.3 to 1.4 in 15'... and the "problem" was not Seaside-Pharo incompatibilities, but to adapt configuration to not load OB (just not choose those packages in the metacello config) Other frameworks like Magritte and Pier ran out of the box. (well... Magritte-Mophic needed a small adjust... and that was like 5') For more examples, my personal projects (I submitted 3 slides yesterday for two of them), are usually complex projects (both for web and desktop) and I migrated all of them in less than a morning work (I needed to update/modify my metacello configurations for that). So... as soon as I know... your feelings are just that: feelings. Not real facts. And maybe those feelings are because we (as a community) are growing and we need to adapt our communication processes to match current status. But I think that's a good think, not a bad one.
We simply have to accept that some developers can have this feelings and try to find a way how to limit it. I think that some official Pharo blog (maybe written by Esteban) would be very helpful. Some kind of not very extensive technical information source that will help people to stay in touch with Pharo progress. That will explain what is being changed in Pharo and why. I think that developers than will see the changes like positive not as alien ones.
As I said above, I agree we need to improve our communication efforts. New times need new ways :) I think a developers blog is a good idea, but I cannot commit myself to produce one weekly blog post, for me a monthly post is more realistic... but I will talk with others and see how can we fulfill that. Also, maybe splitting list as Marcus said is a good step... best, Esteban
On May 16, 2012, at 11:13 AM, Esteban Lorenzano wrote:
99% of the changes affects infrastructure and/or replace old tools. Why your work should be affected by that? I migrated Seaside from 1.3 to 1.4 in 15'... and the "problem" was not Seaside-Pharo incompatibilities, but to adapt configuration to not load OB (just not choose those packages in the metacello config) Other frameworks like Magritte and Pier ran out of the box. (well... Magritte-Mophic needed a small adjust... and that was like 5') For more examples, my personal projects (I submitted 3 slides yesterday for two of them), are usually complex projects (both for web and desktop) and I migrated all of them in less than a morning work (I needed to update/modify my metacello configurations for that).
So... as soon as I know... your feelings are just that: feelings. Not real facts. And maybe those feelings are because we (as a community) are growing and we need to adapt our communication processes to match current status. But I think that's a good think, not a bad one.
+ 10000 May be you should paste that into a blog! And can we have a private developer mailing-list :) Because now our movement is questioned and I do not like that. Stef
Stéphane Ducasse wrote
And can we have a private developer mailing-list :)
What the heck are you guys talking about?! Everyone take a deep breath... Here's the reality: One person who is a) not here to defend himself, and b) (allegedly) not using Pharo (allegedly) made an off-list comment that some developers (allegedly, possibly including himself) may find it jarring that in a year, one could find an unrecognizable latest version of Pharo. This, by the way, is true, even if it may not change our vision or plans. It may be unrecognizable. And, some developers *may* find that unsatisfactory. As we've already established, people do not like change. Now, none of this seems like a reason for all this fuss. It's wasting our time and energy, which is already at capacity making Pharo the system of our dreams. Specifically, I think a private developers list would hurt Pharo both psychologically and physically - we want as many eyes on the issues at hand as possible. Finally, the SO/separate-stackexchange-site/dev/users issue is a separate thing. If we're going to talk about mailing list discipline, let's stop hijacking people's threads. In closing: * Let's all get back to work. People will react emotionally to the massive progress (change) of Pharo. Duly noted, but it's in the damn manifesto ("Not backward compatible" [1]). * Maybe we can improve our communication process, both for the devs and users. Let's discuss that. [1] http://code.google.com/p/pharo/ -- View this message in context: http://forum.world.st/Pharo-is-exploding-tp4630233p4630489.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
This topic went to strange direction. By saying that Pharo exploding i was not suggested to do anything (like creating new mailing lists/stack overflow etc). What i do today is focusing on tasks which i should and filter all other stuff. It is of course a bit frustrating that i cannot track all cool changes and innovations, but i can ask anytime and get response, if i need something. So, no big deal. As for staying on bleeding edge or using/not using Pharo: nobody forcing people to do it. If you like it, you use it, if you don't - you don't. Personally, i prefer seeing "i don't use pharo because it moves too fast" over "i don't use pharo because it don't have things i need" -- Best regards, Igor Stasenko.
Hi, Yeah... but there is a point somewhere there: we need to improve our communication efforts... we need to start thinking as a "growing community" (because that's what I *feel* it is happening). So... which changes would be valuable? I think a developers blog is a good idea (I think we can try to keep it, and we can also ask some non-Lille stablished developers to also talk about what their are doing for Pharo... we are after all an Open Source project, when not everybody lives here, I can think in several names, but you all know them :) Also, I would like to move user questions to: users list or stackoverflow... Why? because that's the purpose of that list ;) So, this list will continue being like now, for the unstable development, but ppl can have a "safe" place where to ask about the stable version. Well... probably something like that would help to easy the development... I will try to start blogging about upcoming changes for Pharo 2.0 (and motives, what can you expect, etc.) right after PharoConf... lets hope that will help a little (not sure, if we take my english level into account, he). best, Esteban On May 16, 2012, at 5:51 PM, Sean P. DeNigris wrote:
Stéphane Ducasse wrote
And can we have a private developer mailing-list :)
What the heck are you guys talking about?! Everyone take a deep breath... Here's the reality: One person who is a) not here to defend himself, and b) (allegedly) not using Pharo (allegedly) made an off-list comment that some developers (allegedly, possibly including himself) may find it jarring that in a year, one could find an unrecognizable latest version of Pharo. This, by the way, is true, even if it may not change our vision or plans. It may be unrecognizable. And, some developers *may* find that unsatisfactory. As we've already established, people do not like change.
Now, none of this seems like a reason for all this fuss. It's wasting our time and energy, which is already at capacity making Pharo the system of our dreams. Specifically, I think a private developers list would hurt Pharo both psychologically and physically - we want as many eyes on the issues at hand as possible.
Finally, the SO/separate-stackexchange-site/dev/users issue is a separate thing. If we're going to talk about mailing list discipline, let's stop hijacking people's threads.
In closing: * Let's all get back to work. People will react emotionally to the massive progress (change) of Pharo. Duly noted, but it's in the damn manifesto ("Not backward compatible" [1]). * Maybe we can improve our communication process, both for the devs and users. Let's discuss that.
[1] http://code.google.com/p/pharo/
-- View this message in context: http://forum.world.st/Pharo-is-exploding-tp4630233p4630489.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Wed, May 16, 2012 at 5:51 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Stéphane Ducasse wrote
And can we have a private developer mailing-list :)
What the heck are you guys talking about?! Everyone take a deep breath... Here's the reality:  One person who is   a) not here to defend himself, and   b) (allegedly) not using Pharo  (allegedly) made an off-list comment that some developers (allegedly, possibly including himself) may find it jarring that in a year, one could find an unrecognizable latest version of Pharo. This, by the way, is true, even if it may not change our vision or plans. It may be unrecognizable. And, some developers *may* find that unsatisfactory. As we've already established, people do not like change.
Now, none of this seems like a reason for all this fuss. It's wasting our time and energy, which is already at capacity making Pharo the system of our dreams. Specifically, I think a private developers list would hurt Pharo both psychologically and physically - we want as many eyes on the issues at hand as possible.
Finally, the SO/separate-stackexchange-site/dev/users issue is a separate thing. If we're going to talk about mailing list discipline, let's stop hijacking people's threads.
Well said. I'm sorry for initiating this direction of discussion and my apologies to Germán that he may be seen now in wrong light. I do not like the idea of the next separate mainling list. Remember huge amount of Squeak mailing lists in past.
From my point of view Pharo finally starts to do real changes. Till now it mainly focused on necessary cleanup of the system and a lot of small changes. And there is no wonder that now we want everything we prayed for as soon as possible. I understand that the tempo may be too fast for some people to follow and as a person that is taking care of Pharo Kernel I know the frustration it can sometimes bring. But it is an extreme case and normal developer should have much less amount of problems.
-- Pavel
In closing: * Let's all get back to work. People will react emotionally to the massive progress (change) of Pharo. Duly noted, but it's in the damn manifesto ("Not backward compatible" [1]). * Maybe we can improve our communication process, both for the devs and users. Let's discuss that.
[1] http://code.google.com/p/pharo/
-- View this message in context: http://forum.world.st/Pharo-is-exploding-tp4630233p4630489.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
100% agree with and I was not emotional just playing drama because I found the discussion so funny. So lets move. There are so many cool stuff along the road. Now reviewing Spec chapter :)
Stéphane Ducasse wrote
And can we have a private developer mailing-list :)
What the heck are you guys talking about?! Everyone take a deep breath... Here's the reality: One person who is a) not here to defend himself, and b) (allegedly) not using Pharo (allegedly) made an off-list comment that some developers (allegedly, possibly including himself) may find it jarring that in a year, one could find an unrecognizable latest version of Pharo. This, by the way, is true, even if it may not change our vision or plans. It may be unrecognizable. And, some developers *may* find that unsatisfactory. As we've already established, people do not like change.
Now, none of this seems like a reason for all this fuss. It's wasting our time and energy, which is already at capacity making Pharo the system of our dreams. Specifically, I think a private developers list would hurt Pharo both psychologically and physically - we want as many eyes on the issues at hand as possible.
Finally, the SO/separate-stackexchange-site/dev/users issue is a separate thing. If we're going to talk about mailing list discipline, let's stop hijacking people's threads.
In closing: * Let's all get back to work. People will react emotionally to the massive progress (change) of Pharo. Duly noted, but it's in the damn manifesto ("Not backward compatible" [1]). * Maybe we can improve our communication process, both for the devs and users. Let's discuss that.
[1] http://code.google.com/p/pharo/
-- View this message in context: http://forum.world.st/Pharo-is-exploding-tp4630233p4630489.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
99% of the changes affects infrastructure and/or replace old tools. Why your work should be affected by that? I migrated Seaside from 1.3 to 1.4 in 15'... and the "problem" was not Seaside-Pharo incompatibilities, but to adapt configuration to not load OB (just not choose those packages in the metacello config) Other frameworks like Magritte and Pier ran out of the box. (well... Magritte-Mophic needed a small adjust... and that was like 5') For more examples, my personal projects (I submitted 3 slides yesterday for two of them), are usually complex projects (both for web and desktop) and I migrated all of them in less than a morning work (I needed to update/modify my metacello configurations for that).
+1 Migrating to 1.4 was not really painful for me neither. The only "problem" was that i had a "startup.st" file lying next to my image that was invoked when launching the VM. In 1.4 it is loaded automatically by Pharo so it was executed twice and messed up my configuration :p I've seen more painful migration (Ruby 1.8->1.9 anyone?).
I will quote Germán (I hope he will not mind): "lot and lot of things... Lot of new things each day. Not time to stabilize nothing.
Stabilize what? What changed so that german cannot work? In 1.4? Come on.
Is needed such acceleration? ... My point is, I'm trying to move a business with Smalltalk and the acceleration of Pharo is well know by me (from other companies) and sooner or later, impact in my job and I'm a very LITTLE software house can't migrate my products all the time."
Then why do you have to migrate? Why not milestoning. I do not migrate all my applications everyday.
We simply have to accept that some developers can have this feelings and try to find a way how to limit it.
May be we should do a break and do nothing?
I think that some official Pharo blog (maybe written by Esteban) would be very helpful. Some kind of not very extensive technical information source that will help people to stay in touch with Pharo progress.
Ok we will do a private mailing-list.
That will explain what is being changed in Pharo and why. I think that developers than will see the changes like positive not as alien ones.
Why people do not register to pharo-users?
-- Pavel
I do not think that the way out from this is to slow down. On the contrary. We simply have to do this era of a lot of big changes as short as possible ;-)
On 5/16/2012 10:06 AM, Stéphane Ducasse wrote:
I think that some official Pharo blog (maybe written by Esteban) would be very helpful. Some kind of not very extensive technical information source that will help people to stay in touch with Pharo progress. Ok we will do a private mailing-list. I would prefer not. I am not a core developer. But I like reading this list. I personally do not find the volume all that big a problem.
Any reasonable mail program can present you with the a threaded view. Allow you to mark threads as read. Read what you want and mark all the rest as read. Or whatever. No one has to read all the messages.
That will explain what is being changed in Pharo and why. I think that developers than will see the changes like positive not as alien ones. Why people do not register to pharo-users? Possibly what we need to do is have a few people who can move or forward discussions to the pharo-users list and encourage non-development-of-Pharo messages there.
But this will require that all the people that we depend upon to answer messages here also subscribe to and respond on pharo-users. If we can do that then over time we will have a culture of the right messages going to the right list. But ultimately, that won't reduce the volume of anything. Neither will using Stack Overflow. Should one be a subscriber to all. Just MHO. Jimmie
It depends. Pharo 2.0 is UNSTABLE. It says it everywhere. If you want to do seriuous development you won't beusing Pharo 2.0, will you? ;)
This is not unstable, this is bleeding edge. When I see how the other applications are crashing. I think that Pharo in alpha is quite stable. Gary did it with pinesoft and he is not toying so this is possible. Moose people decide when the version is getting less changing and it works. Stef
I think we have to improve the foreknowledge about what will happen, why it will happen, what it will mean, what are the related issues etc. I in most cases I have no clue about changes in package structure of the image that are being performed and that require changes in Pharo Kernel processing, initialization etc. As an example I can mention recent CodeImporter integration.
I like the improvements rate but as the side effect it makes Pharo less attractive platform for serious development.
Why? People should not develop in the bleeding edge of the system or at least they should know what they do. I use pharo bleeding edge daily and fix as soon as something goes wrong. Today we even improve Monticello browser feedback and version browsing. Stef
participants (11)
-
Esteban Lorenzano -
Francois Stephany -
Igor Stasenko -
Janko Mivšek -
Jimmie Houchin -
Mariano Martinez Peck -
Max Leske -
Pavel Krivanek -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe