Le 4 sept. 2015 à 12:20, Ben Coman a écrit : > On Fri, Sep 4, 2015 at 3:39 PM, Christophe Demarey > <[email protected]> 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.
smime.p7s
Description: S/MIME cryptographic signature
