On Fri, Apr 13, 2018 at 1:11 PM, Hilaire <hila...@drgeo.eu> wrote: > 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?
Hi Hilaire, Thanks for articulating this. I've been mostly watching Pharo rather than using it, so I haven't been affected by the changes between versions. With respect to commercial products versus Pharo *at the present time*, I think we have different driving forces shaping things. In my opinion, VA Smalltalk has been the one most strongly driven by the importance of backward compatibility and ease of migration to a new version. VisualWorks has been pretty good about providing a path forward with minimal pain, although the more major version numbers difference, the harder it is to transition. Likewise, GemStone/S has a strong emphasis on keeping our customers' existing applications running with minimal changes. That being said, I have no doubt that the earliest versions of all these products had substantial incompatibilities between versions. I am also pretty sure there is a threshold beyond which the adoption of Pharo in business applications will compel Pharo development to facilitate migration to newer versions and to better maintain API compatibility. [And that may be simply because, as more businesses rely on Pharo, they will be financially supporting its development.] A second consideration is the size of the product teams (measured in full-time staffing). I think the commercial products had a much larger staffing in their early days than Pharo has even now. And I think the consequence of that is that the changes between v1 and v2 or between v2 and v3 of the commercial products *may* have been comparable to the differences between Pharo v(n) and v(n+3). Richard > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > >
