We should not continue this old discussion. We've already debated this ad naseum. Thank you Pharo guys for exploring what can be done when all constraints are removed! Thank you Squeak guys for advancing in a way that caters to legacy applications.
On Fri, Oct 25, 2013 at 1:25 PM, Levente Uzonyi <[email protected]> wrote: > On Fri, 25 Oct 2013, Stéphane Ducasse wrote: > >> >>> I'm sorry if you guys didn't get my message, but it was as serious as it >>> could be. >> >> >> Ok fair :) >> >>> I understand that you don't what to be backwards compatible, because it >>> makes it easier to change stuff. >>> As I see, people need various levels of backwards compatibility. >> >> >> Indeed but the right level is important ;) >> I help maintaining Moose and its several couple of tenth of packages as >> well as the pharoExtras packages >> so I think that I'm exposed to API changes. Just today I fixed the >> PharoSound package (full of ugly code BTW) > > > That's nice, but AFAIK Moose is Pharo-only, so you only have to follow your > own changes. > > >> >>> Currently the package maintainers are the most affected, who would like >>> to provide the same codebase for various versions of Pharo, and/or other >>> Smalltalk dialects. >> >> >> there is a bit of utopia there but why not. I prefer to see a system >> getting better than my code just loading in >> a system slowly improving. I can control when I want to migrate my apps. > > > This is where the level of backwards compatibility comes into the picture. > For example the official release of Seaside is still based on Pharo 1.3, and > the reason for that is the frequent changes of core functionality. > > >> >>> As time passes, and the number of users increases, you'll have to give >>> in, and provide it some way. >> >> >> What I was thinking for example (and I will build it) is an automatic stub >> creation to support the >> loading of package where a class is missing in the existing system. > > > I don't see how this is benefical, or how it addresses the increasing demand > for backwards compatibility. > > >> I also love the evolution analysis made by andre that generates rules to >> check migration >> we should add automatic code transformation. I would like to keep >> refactoring that we can apply >> when people want to migrate. And we will get there because we start to >> have a good infrastructure. >> So once the infrastructure does not suck all our time then we will build >> the next generation tools. >> And this is starting :) >> >> >>>> We are all committed to build a robust and clean system that people can >>>> use to >>>> create their own wealth and feed their family. We are >>>> making HUGE progress. I mean REALLY HUGE and the space it opens is >>>> LARGE. >>> >>> >>> I'm not following the developement of Pharo closely anymore, mainly >>> because it's not transparent enough for my taste. >> >> You will complain about the fogbuz stuff and we will answer that we hate >> that google forced us >> to move. And this is like that. > > > Well, fogbugz is just part of it, and somewhat less important than actual > code changes. > There are two kind of diffs posted to this mailing list. One for the changes > on smalltalkhub, and the other is from github. The latter is totally > useless, because it contains no code, just the name of the methods in the > changed packages. The former is totally broken, because smalltalkhub can't > create the diff, if the direct ancestor of the package is missing, and in > 90%+ of the cases, you jump more than one mcz versions. > > >> >>> I see that you're making big changes, but I still haven't seen the >>> breakthrough: I don't see the advantage of using Pharo over another open >>> source Smalltalk dialect, from business point of view. >> >> >> It is just a question of view. For me a new compiler, debugger, inspector, >> filesystem, http >> server and many more is enough. And in addition the consortium means that >> slowly >> we will give an autonomous live to Pharo not based on free time of people. > > > I can only repeat myself; these changes are great, but it's not a > breakthrough. > > > Levente > >> >> Stef >> >> >
