Design Principles Behind Smalltalk, Revisited
Marcel Weiher
marcel at metaobject.com
Wed Jan 3 08:02:24 UTC 2007
On Dec 28, 2006, at 10:51 , Jecel Assumpcao Jr wrote:
[also snipped rather radically]
>
>> [community around a new Squeak?]
>
> That is something I thought a lot about back in 1998. And I watch
> closely the community's reaction to stuff like Coke or Slate. What I
> concluded was that there are several rather different groups. The
> largest group is the eToys users and they are extremely under
> represented here. There is a tiny "use Squeak to build something
> better"
> group but most people here are in the "we need a great open source
> Smalltalk-80" (there is a lot of overlap, of course). So I don't see
> how
> you can change things and not lose a significant part of this
> (squeak-dev) community.
In theory: refactor. Make the the "something better" something that
is more abstract than either eToys or Smalltalk-80 and allow it to
have "subclasses" that are, in effect, eToys and a great
Smalltalk-80. Which is not the same as a big bowl of everything at
once.
>> Increasing complexity is easy; moving it around in tradeoffs is
>> harder;
>> reducing it is hardest and generally require a leap of the
>> imagination.
And/or a lot of refactoring... :-) Or rather: refactorings that
require a leap of the imagination. But probably not "extensions" to
what is already there.
>> Sorry to say it, but Squeak still seems pretty complex to me, and
>> moreso
>> than ten years ago. :-)
>
> Which is why it is a good thing that the version of Neo Smalltalk I am
> working on right now is 16 bits. When you only have 32K objects total
> simplicity is not optional.
That is probably a good learning experience, but I am not sure that
this is the same kind of simplicity.
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070103/55652d56/attachment.htm
More information about the Squeak-dev
mailing list
|