election details *PLEASE READ*

karl karl.ramberg at comhem.se
Thu Feb 22 21:44:07 UTC 2007


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 ? 
What can  the board do to help in this effort ?

Karl



More information about the Squeak-dev mailing list