2010/3/6 Miguel Enrique Cobá Martinez <miguel.coba at gmail.com>:
> El vie, 05-03-2010 a las 22:43 +0100, Bert Freudenberg escribió:
>> On 05.03.2010, at 22:04, Miguel Enrique Cobá Martinez wrote:
>> >
>> > El vie, 05-03-2010 a las 21:07 +0100, Michael Haupt escribió:
>> >> Hi Miguel,
>> >>
>> >> Am 05.03.2010 um 20:46 schrieb Miguel Enrique Cobá Martinez <miguel.coba at gmail.co
>> >> m>:
>> >>> That is better? :)
>> >>
>> >> nah. If yer intae oinchis, take a proper truck. ;-)
>> >>
>> >> Seriously, I see your point, and I think we agree that it really boils
>> >> down to interest.
>> >
>> > Exactly. And that is precisely the issue that Pharo is solving. Squeak
>> > don't give a cent about other uses outside of educational ones. They
>> > have its point, I concede.
>>
>> There is no point to concede, that's simply a false accusation. I have no problem discussing actual issues, but I'd appreciate if you took unfounded bashing elsewhere.
>
> Well that's your opinion, I maintain mine.
>
>>
>> Fact is, most of the developers on this list are *not* working on educational subjects. They want a practical Smalltalk that *includes* support for every conceivable use case.
>
> That is the problem, Squeak is like a swiss knife, with everything
> loaded just in case you needed. Most people just want or a knife or a
> screwdriver, not everything in a big unpractical tool. Pharo can be a
> knife or a screwdriver. Or can be a swiss knife if you want want (but
> this serves only during development time, not on deployment time).
>
>
I think that Squeak and Pharo not too different (yet) to be described
in such manner.
I know that in both camps we want to have clean & lean things, which
easy to load and unload.
So, where you see difference, i see the commonality.
The difference lies mainly in other field - in what way to achieve
this, what tools to use, how to organize tasks
 etc etc.

> But hey, here we go again, discussions and discussions. I'm tired, keep
> discussing. I just answered this thread because someone said that Etoys
> will never be included in Pharo, and I said that if it were a loadable,
> independent-of-squeak package, it would have by now a
> ConfigurationOfEtoys in Pharo as just as Seaside have.
>
> About of Squeak directions, I don't care anymore. If someday Squeak can
> have every package loadable from squeaksource, good, I will load it from
> my Pharo image. If Squeak never get to that point and remains to use the
> monolitical image as a medium of conveying every and each package in the
> world, well, it is 2010, even MS windows can have Internet Explorer
> unloaded from the OS. The monolithic image pertains to the paleolithic
> era.
>
> So long.
>
>
>
>>
>> > But Pharo is the way to go for a lot of people that want a medium for
>> > deploying enterprise application (web or desktop).
>>
>> As is Squeak. There are enterprise desktop applications as well as web ones built in it. But that's besides the point.
>>
>> Pharo is moving faster towards a smaller modular image. Squeak is on that way too, but we are slower because we are trying to not burn bridges. Refactoring something to be unloadable and reloadable is more work than just ripping out what's considered unnecessary (plus Squeakers consider less things unnecessary). *That* is the major current difference between Squeak and Pharo.
>>
>> But eventually I fully expect the two to become more similar as both get leaner and more modular. There could even be a point where e.g. Etoys would work as well on top of a Pharo kernel image as a Squeak kernel image. We just have differing approaches about how to get from here to there.
>>
>> Have fun,
>>
>> - Bert -
>>
>>
>>
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.