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
