+9

This is one of the most concise descriptions of Smalltalk I have ever read. It reminds me of G. Spencer-Brown's description of evolution of signal through a form.

John Sarkela

On Aug 24, 2010, at 9:31 AM, Alejandro F. Reimondo wrote:

> 
>> Smalltalk is a dynamic fuctional object-oriented language.
> 
> Smalltalk is a trayectory in time; it what happens to a body
> in-formation when it change through time ... and survives
> that "unique" experience.
> It is not it's "definition" nor it contents; because it can
> change while you are still trying to constrain it to a
> description.
> Relax and use the part of your smalltalk in the computer;
> but don't forget that there are other parts of your smalltalk
> (some parts outside computer and otehr parts seen
> only in retrospective -sometimes described as
> software evolution- ).
> 
> have a good smalltalking day,
> Ale.
> 
> 
> 
> 
> 
> 
> ----- Original Message ----- From: "Rob Withers" <reefedjib at gmail.com>
> To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
> Sent: Tuesday, August 24, 2010 10:19 AM
> Subject: Re: [squeak-dev] Smalltalk and functional programming
> 
> 
>> You can write a Y-combinator in Smalltalk.  As you point out you can write Function objects.  You can do currying.  You can do eval.
>> 
>> Smalltalk is a dynamic fuctional object-oriented language.
>> 
>> Rob
>> 
>> --------------------------------------------------
>> From: "Frank Shearar" <frank.shearar at angband.za.org>
>> Sent: Tuesday, August 24, 2010 8:58 AM
>> To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
>> Subject: [squeak-dev] Smalltalk and functional programming
>> 
>>> Hi,
>>> 
>>> I'm engaged in a discussion with someone (http://stackoverflow.com/questions/3527753) on whether Smalltalk is or is not a functional programming language.
>>> 
>>> Now admittedly no one in the argument has defined what exactly checkboxes a language needs to tick to qualify as an FPL. (Also, "Foo is/is not a Bar" discussions tend to generate more heat than light.)
>>> 
>>> So at any rate, my position is that because it's natural and idiomatic to program in Smalltalk in a functional way (see Point class and the Collection API - #collect:, #select:, #reduce: and friends), yes, Smalltalk is a FPL.
>>> 
>>> I'm not quite sure what position igouy holds. Or, rather, I know that he (I'll just use the English male pronouns here for brevity) says that Smalltalk's not a FPL, but I'm not sure why. He talks of there being no way to define named functions outside of a class as being the reason, but I'm sure that can't be all of it. (You can - Smalltalk at : #square put: [:x| x * x] - but that's hardly idiomatic.)
>>> 
>>> At any rate, I've spent a while thinking about the matter, so I'm happy either way.
>>> 
>>> It seems to me that the _real_ reason one might label Smalltalk as not being a FPL is mutable state.
>>> 
>>> You can, with a smidge of discipline, happily write a functional object. But it's just as easy to write a mutable object.
>>> 
>>> Point is a good example of a Value Object (aka "immutable state") as is, if I recall correctly, Rectangle: methods either return part of the state of an object (0 at 0 x) or, if they're state-mutating, return a new object with the required state (0 at 0 translateBy: 1 at 1). There's a mild hiccup here, where your "return a new object with new state" must initialise the new object. Point does this by having #setX:setY: in the 'private' category.
>>> 
>>> But this discipline isn't enforced by the language/environment, which for some might be a necessary condition for FPL-ness.
>>> 
>>> Or have I missed the point of what makes a language an FPL?
>>> 
>>> frank
>>> 
>>> 
>> 
> 
> 
>