>>>> Is the current system simple and minimal?
>>>
>>> No, it is complex and it is getting bigger with every release.
>>>
>>>> Do you think the Pharo we have is good enough to have a future?
>>>
>>> No, there is a lot to be improved. I think the future of Pharo is what
>>> can be built on top, not what can be integrated and forced upon
>>> everybody.
>>
>> So? Maybe we should just stop and do something else.
>
> No and yes.
>
> No, don't stop: The cleanup process in Squeak 3.9, Pharo 1.0 and Pharo
> 1.1 was awesome. The system got smaller and more stable with every
> release.
>
> Yes, do something else. Be your own customer. Where is the next Reflectivity?
Do you think that we are not using Pharo? We are. And we got burned. When is
the last time I was using a decent browser?
I do not know. Why because I cannot wati 30 min that the tools get loaded in
the integration image. Since I burn images like hell
one every two minutes.
So why did we start more than one year ago to work on a fast binary serializer?
I let you guess. But the road is still long.
Now just let me tell you that the state of the code definition was so awful (I
mean really really really awful)
that we burnt hours with johan brichau (far from an idiot), veronica and ben.
Benjamin lost days because of this fucking state of the system to build a
simple messageListbrowser.
Why
because a class comment is a method definition with the selector
starting with C
because the abstraction were wrong or inexistant, not class
definition...
So may be you do not like Ring and this is ok.
Now I want an abstraction so that we can build a remote browser by plugging
simply rTalk + nautilus + ring.
With the current state of the system this was simply impossible.
I want to be able to browse senders in the past and compare them with the
current version. Because we use
prehistorical tools even if we could have something like torch to help us.
I cannot see anymore SystemChangeNotifier (even if this was far better than
without)
PackageInfo, PackageOrganizer with lazy identification of packages
so that when you do an analysis you have to ask sometimes twice to
packageOrganiser and packageInfo. Ask cyrille the time he spent there.
I want one good browser, one code model (to be used by all the tools), one
system notifier and a good one.
One AST.
For example, did you check the size of Zinc, much larger than the previous
crap. So?
What conclusion should we draw?
Fuel will have probably more classes than IS, DataStream, SmartRefStream but
more tests....
And pluggable.
So once we will achieved that then it will be ok.
And again again again our goal is to have a modular system. At ESUG I was
discussing with goran and other
to see how we could have pluggable traits in the kernel (so that we can have a
kernel without them).
Now lukas it would be good that we all spend less time reading and writing
these mails.
Stef
