Sometime Pharo frustrate me a lot, I felt it too in the message from Benoit, in the other hand its community is very kind and always helpful. So it is not about blaming people.

In my opinion, there are too much things pushed at the same time in Pharo. You can't push too much things into the box, then when people complain about it to be overfull and bugged request them to fix it, I don't think it can work that way, at this scale of changes. In the other, this is not really what happen here, I very likely exaggerate this trait but you get the idea.

For example, I developed DrGeo for several years on P3. Why sticking to P3? It gave me the opportunity to fine craft DrGeo to be stable and predictable in the way it behaves to its end users, and a lot of releases occurred. When I started to look at porting to newer image last June, I realizedĀ  DrGeo will become unstable and oversized, so can of turning from A+ grade to a D- grade, just by the magic of porting it. My plan was to port it during the summer to get it ready end of August to deploy in local schools, it does not happen. And I can write it: it is s-u-p-e-rĀ  f-r-u-s-t-r-a-t-i-n-g. Is it normal when porting code? I don't know, I am a casual developer, but it makes developing well crafted and reliable Pharo application a bit expensive to my taste. To such a scale that I started to evaluate alternative to Pharo as the underneath system, idea I finally gave up after several weeks of evaluations. All in all I still have this felling Pharo is not developer friendly, I fell DrGeo is not secure there. See when porting to newer image, I end up using P7-32bits alpha on Linux because it was the most comfortable situation comparing to P5/P6/P6.1, is it not strange?

In the other hand this struggle occurs at image change. Ok, may be it is a pattern specific to Smalltalk. Is it the case with commercial Smalltalk vendors?


Dr. Geo

Reply via email to