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.