Re: [Pharo-users] Where do we go now ?
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
On Fri, Apr 13, 2018 at 1:11 PM, Hilaire <hilaire@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
On 14 April 2018 at 01:52, Richard Sargent <richard.sargent@ gemtalksystems.com> wrote:
On Fri, Apr 13, 2018 at 1:11 PM, Hilaire <hilaire@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.]
You would expect this be a natural progression as more companies supporting such priorities join the consortium. The corollary is that its better the take greater leaps earlier when there is a greater percentage of Innovators and Early Adopters who are willing to ride some rough edges for the benefit they gain *now*. When the Majority arrive, such changes would be more disruptive to perception of Pharo i.e. more opinons, less care. cheers -ben
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
Regarding the problems I have with my firstname and file paths and utf-8 encoding, I found something weird in the UTF-8 encoding. In fact, to be more precise, I found something strange when converting a String to a ByteArray (which UTF-8 encoders convert from) If I look at the example in the comment of ByteArray>>utf8Decoded, 'Les élèves français' is encoded as: #[76 101 115 32 195 169 108 195 168 118 101 115 32 102 114 97 110 195 167 97 105 115] NOW, if I take that very same string, 'Les élèves français' , and convert it to a ByteArray, I get : 'Les élèves français' asByteArray printString. #[76 101 115 32 233 108 232 118 101 115 32 102 114 97 110 231 97 105 115] The 2 don't match! By the way, this problem exists on Pharo 5.1, 6.1 and 7.1 (on Windows 10 ) Can anyone confirm/infirm on another platform to see if this is Windows-specific? ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)
participants (4)
-
Ben Coman -
Benoit St-Jean -
Hilaire -
Richard Sargent