Need a decision on subString: vs substring:
*) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:. I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
why not both ? On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote:
*) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
We went through a lot of effort/pain to move to substring, I think for good reasons.
On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
why not both ?
Because the proper English spelling is with lowercase https://duckduckgo.com/?q=define%3A+substring&ia=definition
On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote: *) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks. On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We went through a lot of effort/pain to move to substring, I think for good reasons.
On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
why not both ?
Because the proper English spelling is with lowercase
https://duckduckgo.com/?q=define%3A+substring&ia=definition
On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote: *) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
On Fri, Sep 4, 2015 at 4:44 AM, Gabriel Cotelli <g.cotelli@gmail.com> wrote:
I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.
On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We went through a lot of effort/pain to move to substring, I think for good reasons.
On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
why not both ?
Because the proper English spelling is with lowercase
+1. As a consequence, its the form that has won industry wide. Aligning on this provides a small part of an accumulation of items that lower the friction of adoption from the wider industry. On the flip side, even though are potentially more non-Smalltalkers who may adopt Pharo, others from existing Smalltalker dialects may be more likely to transfer, so its good to not alienate them. So it may be useful to have an ANSICompatibility package available in the Catalog Browser that you can point people to - a box to tick on the checklist to reduce the barriers to entry. cheers -ben
https://duckduckgo.com/?q=define%3A+substring&ia=definition
On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote: *) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
+1 for an ANSICompatibility package ... ANSI shouldn't hold Pharo back, and an ANSICompatibility package allows for cross-dialect code sharing which was the aim of the ANSI standard in the first place. Dale On 9/3/15 5:51 PM, Ben Coman wrote:
On Fri, Sep 4, 2015 at 4:44 AM, Gabriel Cotelli <g.cotelli@gmail.com> wrote:
I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.
On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We went through a lot of effort/pain to move to substring, I think for good reasons.
On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
why not both ? Because the proper English spelling is with lowercase +1. As a consequence, its the form that has won industry wide. Aligning on this provides a small part of an accumulation of items that lower the friction of adoption from the wider industry. On the flip side, even though are potentially more non-Smalltalkers who may adopt Pharo, others from existing Smalltalker dialects may be more likely to transfer, so its good to not alienate them. So it may be useful to have an ANSICompatibility package available in the Catalog Browser that you can point people to - a box to tick on the checklist to reduce the barriers to entry.
cheers -ben
https://duckduckgo.com/?q=define%3A+substring&ia=definition
On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote: *) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
Ben Coman wrote
Because the proper English spelling is with lowercase +1.... So it may be useful to have an ANSICompatibility package
+1 to having the proper spelling (that we've fought so hard to have) as the only one in the image. And +1 for a compatibility package if there is a proven demand for such a thing. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p48... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I am confused till now I have been reading that pharo does not care about the past or does not care about being another Smalltalk implementation and it cares only being Smalltalk inspired . What changed in the meant time ? Why so much talk about other Smalltalks and ANSI-Smalltalk ? On Sat, Sep 5, 2015 at 6:28 AM Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
Because the proper English spelling is with lowercase +1.... So it may be useful to have an ANSICompatibility package
+1 to having the proper spelling (that we've fought so hard to have) as the only one in the image. And +1 for a compatibility package if there is a proven demand for such a thing.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p48... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I am confused till now I have been reading that pharo does not care about the past or does not care about being another Smalltalk implementation and it cares only being Smalltalk inspired . What changed in the meant time ? Why so much talk about other Smalltalks and ANSI-Smalltalk ? Nothing we do not diverge for the fun in general. We diverge to improve (of course people can discuss it and think that we are idiots) Now if adding a method in a package can help people porting to Pharo we should not be stupid :)
Stef
On Sat, Sep 5, 2015 at 6:28 AM Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
Ben Coman wrote >>> Because the proper English spelling is with lowercase > +1.... So it may be useful to have an ANSICompatibility package
+1 to having the proper spelling (that we've fought so hard to have) as the only one in the image. And +1 for a compatibility package if there is a proven demand for such a thing.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p48... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I don't like so much compatibility packages because people will not update their code and expect the compatibility package to always work. Why not just use what Marcus did for deprecations? Create a rule to transform ANSI Smalltalk to Pharo "magicly'? Le 3 sept. 2015 à 22:44, Gabriel Cotelli a écrit :
I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.
On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: We went through a lot of effort/pain to move to substring, I think for good reasons.
On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
why not both ?
Because the proper English spelling is with lowercase
https://duckduckgo.com/?q=define%3A+substring&ia=definition
On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote: *) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
2015-09-04 9:39 GMT+02:00 Christophe Demarey <Christophe.Demarey@inria.fr>:
I don't like so much compatibility packages because people will not update their code and expect the compatibility package to always work. Why not just use what Marcus did for deprecations? Create a rule to transform ANSI Smalltalk to Pharo "magicly'?
An extension package with a set of rewrite rules that we can use to: - port code for old Pharo versions to new Pharo versions (in some areas of Pharo, many things disappear/are renamed without deprecation between versions) - port non-Pharo code to Pharo. It would be really great if those rules could be applied when loading the package via MC or FileIn, not when the package is already loaded, otherwise you need both a compatibility layer, and the rewriting rules. Probably a lot easier to do by, say, replacing the MC code model by the RB code model. Or, when loading a package, loading it through a MC defintion, convert it to RB model, apply rules, convert to Ring, compile Ring... I like simple things :) Thierry
Le 3 sept. 2015 à 22:44, Gabriel Cotelli a écrit :
I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.
On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We went through a lot of effort/pain to move to substring, I think for good reasons.
On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
why not both ?
Because the proper English spelling is with lowercase
https://duckduckgo.com/?q=define%3A+substring&ia=definition
On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote: *) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
On Fri, Sep 4, 2015 at 3:39 PM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
I don't like so much compatibility packages because people will not update their code and expect the compatibility package to always work. Why not just use what Marcus did for deprecations? Create a rule to transform ANSI Smalltalk to Pharo "magically'?
People updating their code when porting is better than using a compatibility package. But having code ported is better than not-having code ported, if its perceived we are making it harder than necessary. If someone wants to continue maintaining their software in the original Smalltalk dialect, *forcing* their code from #subStrings to #substrings is one more difference you've *imposed* on them to maintain in their own compatibility layer. Its the sort of annoyance that can taint people's emotional buy-in to a new system. This again reminds me of a story about when Excel took over from Lotus (which I've posted before) which I think applies to code being ported from one system to another... "Excel's tipping point [...] happened around the time of Excel 4.0. And the biggest reason was that Excel 4.0 was the first version of Excel that could *write* Lotus spreadsheets transparently. Yep, you heard me. *Write*. Not read. It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. [...] To take over a market, you have to address every barrier to entry. If you forget just one barrier which trips up 50% of your potential customers, then by definition, you can't have more than 50% market share, and you will never displace the dominant player, and you'll be stuck on the sad (omelet) side of chicken and egg problems." [1] [1] http://www.joelonsoftware.com/articles/fog0000000052.html The corollary being, if you make it simple for people to continue maintaining the old dialect, you are more likely to get code ported to your dialect. cheers -ben
Le 3 sept. 2015 à 22:44, Gabriel Cotelli a écrit :
I've second Sven here. In case anybody wants the old method put it in some ANSICompatibility package to ease porting packages from ANSI-compliant Smalltalks.
On Thu, Sep 3, 2015 at 4:54 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We went through a lot of effort/pain to move to substring, I think for good reasons.
On 03 Sep 2015, at 21:31, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
why not both ?
Because the proper English spelling is with lowercase
https://duckduckgo.com/?q=define%3A+substring&ia=definition
On Thu, Sep 3, 2015 at 9:45 PM stepharo <stepharo@free.fr> wrote: *) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:.
I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.
Le 4 sept. 2015 à 12:20, Ben Coman a écrit :
On Fri, Sep 4, 2015 at 3:39 PM, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
I don't like so much compatibility packages because people will not update their code and expect the compatibility package to always work. Why not just use what Marcus did for deprecations? Create a rule to transform ANSI Smalltalk to Pharo "magically'?
People updating their code when porting is better than using a compatibility package. But having code ported is better than not-having code ported, if its perceived we are making it harder than necessary. If someone wants to continue maintaining their software in the original Smalltalk dialect, *forcing* their code from #subStrings to #substrings is one more difference you've *imposed* on them to maintain in their own compatibility layer. Its the sort of annoyance that can taint people's emotional buy-in to a new system. This again reminds me of a story about when Excel took over from Lotus (which I've posted before) which I think applies to code being ported from one system to another...
"Excel's tipping point [...] happened around the time of Excel 4.0. And the biggest reason was that Excel 4.0 was the first version of Excel that could *write* Lotus spreadsheets transparently. Yep, you heard me. *Write*. Not read. It turns out that what was stopping people from switching to Excel was that everybody else they worked with was still using Lotus 123. [...] To take over a market, you have to address every barrier to entry. If you forget just one barrier which trips up 50% of your potential customers, then by definition, you can't have more than 50% market share, and you will never displace the dominant player, and you'll be stuck on the sad (omelet) side of chicken and egg problems." [1]
[1] http://www.joelonsoftware.com/articles/fog0000000052.html
The corollary being, if you make it simple for people to continue maintaining the old dialect, you are more likely to get code ported to your dialect.
I agree with that. To be compatible with these goals, I think my proposition just needs to be updated a bit. I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI code when it gets loaded in the image.
...
The corollary being, if you make it simple for people to continue maintaining the old dialect, you are more likely to get code ported to your dialect.
I agree with that. To be compatible with these goals, I think my proposition just needs to be updated a bit. I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI
code when it gets loaded in the image.
No, it's not! Rewriting the code in this case is actually a very bad thing. The problem is that when you port changes done in, say, Pharo back to, say, "The other cool Smalltalk" you have rewrite everything back (or things will break). This is not what you want to spend you time on. So either don't enforce code rewriting in this case or be honest and say openly "I do not care, not my problem" :-) And no, I'm not theorizing, I'm talking out of my every-two-weeks-or=-so-pain I'm suffering last year or so. Best, Jan
On Fri, Sep 4, 2015 at 6:18 AM, Christophe Demarey < Christophe.Demarey@inria.fr> wrote: <snip>
I agree with that. To be compatible with these goals, I think my proposition just needs to be updated a bit. I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI code when it gets loaded in the image.
True to a point. That point being folks who want to write code that could play in other ANSI Smalltalks - with your approach, you have locked those people out, since they CAN'T write ansi code - only Pharo code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - and they'd leave to write and live in a different Smalltalk. Now, if you had the ANSI compatibility layer that either allowed conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a barrier. On a different topic, what would be required to amend the ANSI standard? Maybe a Smalltalk Agreement 2016 that took the standard and amended some parts (like fixing the spelling) so that going forward, all Smalltalks could be standard with good English spellings? Just curious, cbc
I agree with that. To be compatible with these goals, I think my proposition just needs to be updated a bit. I'm still in favor of rules to transform ANSI code to Pharo code. The point is that we should not force the user to update their code base. The rule-cased approach is compatible with that if you transform ANSI code when it gets loaded in the image.
True to a point. That point being folks who want to write code that could play in other ANSI Smalltalks - with your approach, you have locked those people out, since they CAN'T write ansi code - only Pharo code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - and they'd leave to write and live in a different Smalltalk.
Now, if you had the ANSI compatibility layer that either allowed conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a barrier.
On a different topic, what would be required to amend the ANSI standard? Maybe a Smalltalk Agreement 2016 that took the standard and amended some parts (like fixing the spelling) so that going forward, all Smalltalks could be standard with good English spellings?
Chris ANSI is not really good. It is old. And the time investement would be enormous to improve and nobody would care. I read it with attention about strings for example. Because the String API is not really nice in any Smalltalk but this is another story. I do not expect anything from Ansi or any improvements. Let us face it when VW change syntax, added namespaces or whatever they did not care about ANSI. So adding a compatibility package is the way to go. Stef
We have quite a lot of instances of #subString: in Seaside. The deprecation makes loading painful. What is the decision? Stephan
Hi, I'm not sure what's the decision, however, as a pain-relief I committed just couple days ago CompatibilityANSI to http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility For now it only defines subStrings: :-) On Sun, 2015-09-20 at 16:08 +0200, Stephan Eggermont wrote:
We have quite a lot of instances of #subString: in Seaside. The deprecation makes loading painful. What is the decision?
Stephan
What is the decision? The consensus seemed to be #substrings:, and a compatibility package if necessary.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p48... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 20 Sep 2015, at 19:14, Sean P. DeNigris <sean@clipperadams.com> wrote:
What is the decision? The consensus seemed to be #substrings:, and a compatibility package if necessary.
⦠because substring is real english while subString is not, AFAIK :)
Cheers, Sean
View this message in context: Re: Need a decision on subString: vs substring: <http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p48...> Sent from the Pharo Smalltalk Developers mailing list archive <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at Nabble.com.
participants (13)
-
Ben Coman -
Chris Cunningham -
Christophe Demarey -
Dale Henrichs -
Dimitris Chloupis -
Esteban Lorenzano -
Gabriel Cotelli -
Jan Vrany -
Sean P. DeNigris -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier