2010/8/26 Levente Uzonyi <leves at elte.hu>:
> On Wed, 25 Aug 2010, Pavel Krivanek wrote:
>
>> 2010/8/25 Levente Uzonyi <leves at elte.hu>:
>
> snip
>
>>>
>>> Sorry, but I totally don't get what you're talking about. IMHO Pharo's
>>> Kernel/Collections/Network/Compiler is (far) behind Squeak's. I think
>>> Pharo
>>> lacks developers who have enough knowledge to touch those parts of the
>>> system and are willing to spend their time on it. But I may be wrong, so
>>> please let me know how is PharoKernel/Core better than Squeak.
>>
>> Pharoers are preparing Opal and Ocean so at least it is not right that
>> they don't have enough courage and skills to touch this parts. As
>
> Those are "external" packages. Maybe they will replace the Compiler and
> Network packages in Pharo someday. But if they can be changed in Pharo, it's
> very likely that they can be changed in Squeak if needed. I think Ocean
> won't be succesful for networking with Alien and Opal will hardly have the
> same performance as the current compiler, though both packages have several
> other advantages.
> Anyway, these aren't examples for "Pharo developers enhancing the existing
> packages" which is what I was talking about.
>
>> someone who tried to be in touch with Pharo development from the
>> perspective of my previous modularization effort I had to say that the
>> amount of important changes in Pharo is really huge.
>
> You mean those changes which weren't taken from Squeak?
>
>>
>>>> full-timers now. And original goals of Squeak are very different from
>>>
>>> Hiring more people doesn't mean it will be better.
>>>
>>>> duplicating of effort already done somewhere else. Squeak has to face
>>>
>>> What are the original goals of Squeak besides being a general purpose
>>> free
>>> Smalltalk?
>>
>>> From Back to the future: "In December of 1995, the authors found
>>
>> themselves wanting a development environment in which to build
>> educational software that could be used?and even programmed?by
>> non-technical people, and by children. We wanted our software to be
>> effective in mass-access media such as PDAs and the Internet, where
>> download times and power considerations make compactness essential,
>> and where hardware is diverse, and operating systems may change or be
>> completely absent. Therefore our ideal system would be a small,
>> portable kernel of simple and uniform design that could be adapted
>> rapidly to new delivery vehicles."
>>
>> Smalltalk was only an instrument.
>
> The goals were to build a portable VM and something like EToys or Scratch?
> If so, those goals were reached long time ago.
>
>>
>>>> to competition of Pharo and EToys. Squeakers can "fight" them or use
>>>
>>> How is EToys competition to Squeak? Is EToys a free general purpose
>>> Smalltalk?
>>
>> Of course not. But for people who want to use EToys, the EToys image
>> is more natural choice. That was the main reason why Pharoers stopped
>> to support it because it was only a dead weight. For them the concept
>> of general purpose Smalltalk (of the Sqeuak's way) is antiquated.
>>
>> The KernelImage project tried to show that it is possible to have a
>> modular Smalltalk with EToys support. But I did it only because it was
>> possible not because I really trusted it is a vital concept. I
>> supposed that the fact that we will have EToys in a separate package
>> will probably show that nobody cares about its support (however I
>> didn't wanted that).
>>
>> Please, can you tell me for what target group of users the Squeak is
>> and how it differs from Pharo and EToys? Because I'm confused in that.
>
> Pharo originally targeted developers(*), but now it has the same target
> audience as Squeak.
>
>
> Levente
>
> (*) Though I didn't see Stephane's presentation at ESUG 2009, but people
> were fascinated by it and foretold the death of Squeak, even though Pharo
> wasn't really different from Squeak+Polymorph back then:
> http://www.cincomsmalltalk.com/userblogs/mls/blogView?entry=3429226129
> But they were proven wrong. Pharo 1.0 was beta at that time, while Squeak's
> "New Community Developement Model" just started. Pharo 1.0 was released on
> 15 April, 2010, while a week later (on 23 April, 2010) Squeak 4.1 was
> released which was far ahead of Pharo 1.0.
>

This is true, but in my sense entirely explained by the fact Pharo
barrier to commit is higher...
This is due to higher expectations in process quality...
... like filling http://code.google.com/p/pharo/issues/list before any
change, and a bit more formal commit procedure (SLICES, test cases
etc...)
... and like reduced set of people taking responsibility to control
and integrate changes (the process is more demanding than Squeak which
is a weak point of Pharo organization so far).

Trunk organization is really light with lower expectations in process
quality, but is the prefect fit to my own taste, though i deplored
several times that important decisions are not really traced... (a
mailing list archive is not the ideal repository for these).

Nicolas

>>
>> Cheers,
>> -- Pavel
>>
>>> Levente
>>>
>>>> them. Please do not let personal disagreements blind you...
>>>>
>>>> Cheers
>>>> -- Pavel
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>