[squeak-dev] What turns off newcomers

Igor Stasenko siguctua at gmail.com
Tue Apr 8 00:44:31 UTC 2008


2008/4/8 Randal L. Schwartz <merlyn at stonehenge.com>:
> >>>>> "Sean" == Sean Heber <sean at fifthace.com> writes:
>
>  Sean> Historically, you often need a single or small group of focused radicals
>  Sean> in a position of power to effect change - for better or worse.  The
>  Sean> board could be that group of radicals by doing things like getting
>  Sean> together and redefining what "Squeak" actually means.  What it includes
>  Sean> in an image.  What it looks like.  How you use it.
>
>  Oddly enough, that's my vision for the SqF board as well.  And I'm on it.  I
>  believe there needs to be a clear focus, and I'll be working to ensure that
>  the board provides the focus.
>
Count me in :)

As another observation: we should determine somehow the boundaries
which should not be crossed and change dev tools to warn developer
when he crossing these boundaries.
One of most powerful patterns in smalltalk, that we can extend
behavior of base classes like Object
or ProtoObject.
It is good when you just add few new methods, the chance that your
extension will conflict with another package is minimal.
But when you going to override methods or restructure classes(by
adding/removing vars), things getting worser and worser.
Sometimes it is impossible to include a nice workaround or extension
without overriding methods in base(or any other) classes so, ability
to redefine behavior of basic classes should be preserved.
But from the moment when someone needs to change/extend basic things
we getting into trouble of names/versions conflicts when using package
in different images/environment.
This issue, i think, is the main reason why forks appear.
And fork is something which i think is most nasty thing which happens
during development. It leads to fragmentation of developers community,
user base, prevents exchange ideas/improvements and many other things
which i missed :)

If we want Squeak to gain more popularity and flourish, we should make
sure that in future versions a chance of fork will be minimal.
And minimal chance should mean, that developer should have such
image/tools with which he don't needs to make any forks, and be sure
that his application will work rock solid under any circumstances in
any Squeak environment.

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list