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?
Hilaire
--
Dr. Geo
http://drgeo.eu
