election details *PLEASE READ*

Milan Zimmermann milan.zimmermann at sympatico.ca
Fri Feb 23 06:15:40 UTC 2007


On 2007 February 22 16:44, karl wrote:
> J J skrev:
> >> From: Roel Wuyts <Roel.Wuyts at ulb.ac.be>
> >> Reply-To: The general-purpose Squeak developers
> >> list<squeak-dev at lists.squeakfoundation.org>
> >> To: The general-purpose Squeak developers
> >> list<squeak-dev at lists.squeakfoundation.org>
> >> Subject: Re: election details *PLEASE READ*
> >> Date: Wed, 21 Feb 2007 22:52:45 +0100
> >>
> >> I drink do that. Cheers Andreas.
> >>
> >> It's fun that especially a very open and reflective language like
> >> Smalltalk actually is not extended very much (or only within small
> >> research projects not taken up by the community). Where are the
> >> macro  systems ? Variable length argument lists ? Nifty versioning
> >> and  packaging systems ? Monads ? Usable typing systems ? etc. etc.
> >
> > But before we decide a feature is missing from Squeak because someone
> > else has it, we must first think *why* some other place has it.  For
> > an extreme example, C has pointers and Squeak doesn't.  Does anyone
> > think Squeak needs pointers?
> >
> > Likewise, Haskell has Monads.  But that is because there is no other
> > language supported way to represent state change.  It is a very nice
> > language, but for Monads to work right, I think you kind of need the
> > whole thing (i.e. partial application, type checking, the things that
> > make Haskell Haskell).
> >
> > So far, any time I would have reached for variable length argument
> > lists in other languages, I used meta-programming in Smalltalk.  And
> > Macro systems?  It can be put in easily, and I have code that
> > generates code, but due to the nature of Smalltalk, we can add
> > language constructs without having to resort to macros as Lisp does.
> >
> > Having said all that, I think Squeak could use more formal Lazy
> > evaluation support, and I published some classes for it.  And the
> > package system is a known open issue.  I personally believe change
> > sets could be made more advanced to help out in a lot of areas (for
> > one, to help with documenting that elusive "why").
> >
> > I think we should try to take things from other languages that make
> > sense for smalltalk, but I don't think there will be a time when one
> > language (even smalltalk!) will be perfect for every task.  We will
> > still need at least Haskell. :)
>
> Another issue that will come up in the near future is multi core
> processors. What must be done with Squeak to utilize all the processors
> and what are the benefits and drawback of the  different approaches ?

I agree this is an important point, I was in fact thinking adding a question 
about it to the list the election team is organizing, you asked it first 
(below) :)

Milan
> What can  the board do to help in this effort ?
>
> Karl



More information about the Squeak-dev mailing list