First post here ... few days on Squeak ... some questions ....

On Aug 28, 2007, at 4:11 , Fabio Filasieno wrote:

> It's just that I see this great opportunity for smalltalk that with  
> a little fix people like me would appreciate Smalltalk more.
> The messaging system allows me to blend perfectly the mixed bottom-
> up top-down approach that I use in system building, but to do the  
> bottom-up properly... I need the pipe.

"Perfection is achieved, not when there is nothing more to add, but  
when there is nothing left to take away."  (Antoine de Saint-Exupery)


- Bert -

>
> "Perfection is achieved, not when there is nothing more to add, but
> when there is nothing left to take away."  (Antoine de Saint-Exupery)
- Leonard Nemoy, Civilization 4

:)

On Tue, 28 Aug 2007 15:46:31 -0700, Michael Lucas-Smith  
<[hidden email]> wrote:

>
>>
>> "Perfection is achieved, not when there is nothing more to add, but  
>> when there is nothing left to take away."  (Antoine de Saint-Exupery)
> - Leonard Nemoy, Civilization 4
>
> :)

Ha! I was thinking the same thing.

(For those who don't know, this quote is read by Leonard Nimoy in the game  
Civilization IV, after you successfully research the Engineering  
technology.)

>>>
>>> "Perfection is achieved, not when there is nothing more to add,  
>>> but when there is nothing left to take away."  (Antoine de Saint-
>>> Exupery)
Bah!
"Perfection is achieved when *I* damn well say so"
  - tim Rowledge

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Yummy" said Pooh, as he rotated Piglet slowly on the spit.

.> "Perfection is achieved, not when there is nothing more to add, but
> when there is nothing left to take away." (Antoine de Saint-Exupery)

Is he were a Smalltalker, he would have simplified that...
 
thingsToTakeAway ifEmpty:[Perfection achieved]
 
:)
 

---

The next generation of MSN Hotmail has arrived - Windows Live Hotmail

On 28/08/07, Fabio Filasieno <[hidden email]> wrote:
Bloat you say? but if implemented differently it can improve
performance and transform collection using single loop. Instead of:
        ^ (self select: selectBlock) collect: collectBlock
or with pipe syntax:
^ self select: selectBlock | collect: collectBlock

it can be rewritten to:
   | newColl |
   newColl := self species new.
    self do: [ :each | (selectBlock value: each) ifTrue: [ newColl
add: (collectBlock value:each) ] ]
  ^ newColl.

But yes, as a general approach it will be a bloat to implement tons of
methods which will be a composition of different methods of collection
transformations.
That's where the pipes can propose something better and cleaner. But
at the same time, often suboptimal.

--
Best regards,
Igor Stasenko AKA sig.

On 29/08/07, Michael Lucas-Smith <[hidden email]> wrote:
>
> >
> > "Perfection is achieved, not when there is nothing more to add, but
> > when there is nothing left to take away."  (Antoine de Saint-Exupery)
> - Leonard Nemoy, Civilization 4
>
> :)
>
>
Often, to take something away, you need something to add/replace first ;)


--
Best regards,
Igor Stasenko AKA sig.

On Aug 26, 2007, at 1:42 PM, Bert Freudenberg wrote:

Very cool!

Integrating (OO) dataflow, with pipes as a start, has been one of my  
short-term goals with Objective-Smalltalk/Arches.  So far, getting  
something up and running has been surprisingly easy, whereas getting  
something really consistent is proving a bit more elusive, mostly  
because it isn't really clear to me what consistent semantics should  
actually be.

Two examples:

Run an external command with an argument:

 > ls with:'/'
AppleInternal
Applications
Developer
Library
Network
System
Users
Volumes
bin
cores
dev
etc
home
mach_kernel
mach_kernel.ctfsys
net
private
sbin
tmp
usr
var
 >

External command piped into internal filter:

 > (ls with:'/')  | upcase
APPLEINTERNAL
APPLICATIONS
DEVELOPER
LIBRARY
NETWORK
SYSTEM
USERS
VOLUMES
BIN
CORES
DEV
ETC
HOME
MACH_KERNEL
MACH_KERNEL.CTFSYS
NET
PRIVATE
SBIN
TMP
USR
VAR
 >

The filter just processes #writeObject:  messages, with the runtime  
knowing that 'ls' returns text lines and therefore sending it

External command piped into external command (short-circuits so the  
two commands are connected directly)

 > ls | wc
 >        0       3     196

A little synchronization issue at this point....

Marcel

On Aug 26, 2007, at 12:20 AM, Alan Lovejoy wrote:

> Andrew Tween wrote:
>> if we don't want to use up another character, then we could use two  
>> semi-colons.
>> a x:1 ;; y: 2
>
> Actually, whatever token is used, it should NOT be one that would be  
> a legal message selector.  It's new syntax, and messages and syntax  
> should be distinct.

Well, only if you view things that are new as additions to what is  
there.

I prefer to see new things as generalizations or refactorings of what  
is there.

In Arches, I view message sends as a special-case of connectors.  So  
things like := or => or possibly ;; can also just be connectors, but  
ones that are not message sends.

Admittedly, I haven't yet thought wether I can make statement  
separators into connectors.  Superficially, it doesn't look like they  
wouldn't be:  they connect statements (at the same time separating  
them ;-)...

Marcel

On Aug 25, 2007, at 2:44 PM, Fabio Filasieno wrote:

> a := b + c. ^ a
>
> What is := ?
> What is ^ ?
> What is . ?

Answer:  they are all connectors.

> The pipe I have in mind perfectly blends with "messaging" ...  
> because it's just sending a message to the return value of the  
> previous method. Not only.

IMHO, pipe blends even better with "connecting"...

Marcel

On Aug 26, 2007, at 3:10 AM, Fabio Filasieno wrote:

>> Smalltalk is very different - you always can add behaviour you
>> need to the other object and the application logic is distributed
>> across the system.
>
> That's not the point, but you are right, Unix and Smalltalk are  
> different.
> In regard to the black boxes thing.

I think a lot of the differences are superficial, but one seems very  
deep:  Unix's unifying principle is extensional, Smalltalk intensional.

That is, Unix gets its power from the fact that everything is just  
represented as bytes, and you can pipe those around.  Who cares what  
they mean?  To the refined tastes of us Smalltalkers that seems  
barbaric, but it is very powerful in a very pragmatic sort of way, and  
gets you extremely loose coupling and late binding (of things other  
than the fact that it's all just bytes).  Of course, you lose moving  
to higher levels of abstraction, and no, XML doesn't really do it.

Smalltalk, on the other hand, does really well with modelling  
semantics, as objects sending messages, but has a hard time extending  
its unifying principle outside the image.  Which is somewhat ironic  
considering the idea was connecting things and late, late binding.

Marcel

I think a lot of the differences are superficial, but one seems very deep:  Unix's unifying principle is extensional, Smalltalk intensional.

On Wed, 29 Aug 2007 02:41:01 -0700, Fabio Filasieno  
<[hidden email]> wrote:

>  From a first look at the collection libraries, it seems to me that
> there is a LOT of bloat. Really really a LOT.
> I bet that Ocaml's collections can do the same things with an order
> of magnitude of less of code.

Easy enough to demonstrate, at least for starters. Show us a particularly  
bad example in Squeak and the same thing in OCaml. Then how you would  
recommend Smalltalk change. Stephen and his pals redesigned the whole  
collection system in traits to demonstrte their theory. (BTW, anyone know  
how to turn traits visible in the browser?)

But consider the Internet as a real object oriented system ...

Cheers,

Alan

-------------

At 04:50 PM 8/29/2007, Marcel Weiher wrote:

  Hello,

> > Fair enough. I'll be more careful. But, if we where talking face to face you
> > would see
> > a smile on my face not an ... aggressive face.
>
> Well, that's a fair point.  The actual words only count about 10% of
> actual communication, so it can be very hard to judge someones
> intentions.

  Of course, there is no empirical research result that supports a
claim like this (10% or, "7%-38%-55%").  I don't think reasonably
carefully written text (even emails) is less effective than verbal
communication.  If one feels that he has to use many exclamation marks
in a row or many capitalized words when he is supposed to convince
people logically, it is a "smell" of lack of deep logic.

... And going back to the main topic...

  I don't see real benefit to change the language just to achieve a
very tiny, tiny subjective benefit at some corner cases.  As many have
pointed out, the unary messages or binary messages are already "piped"
(strange word, as they are just ordinally chained expressions after
all).  So, insisting that Smalltalk-80 lacks the concept is not simply
true.  And, making an object that holds the current value (or a
context) and sending cascaded messages to it has the same effect, as
Bert and others have shown.  collect:thenSelect: is a weirdo, but
there aren't too many of such guys.

  Many proposed syntax for it in this thread are tiny syntax sugar,
and comes with a lot of unnecessary surprises.  (I like the clever
tricks and aesthetic sense people have shown, though.)

  BTW, to the eyes of a real functional programmer, the message
patterns connected with '|' looks like a pattern matching expression.
This will be another reason to say it is an unnecessary surprise.

  If we think about the magnitude of changes from Smalltalk-72 to
Smalltalk-76 to Smalltalk-80, I hope the change to the language has
that kind of magnitude.  Traits in Squeak really didn't turn out be as
successful as it should have been, but that kind of change, for
example.  Pipe sounds to me like connecting multiple processes.  It
would be a nice change to a language.

  In regards to cascading and semi-colon and these issues, I think
first we can get rid of semi-colon altogether.  Today, a typical use
of cascading is like this:

     self layoutPolicy: TableLayout new;
          listDirection: #leftToRight;
          wrapCentering: #topLeft;
          hResizing: #spaceFill;
          vResizing: #spaceFill

if these keywords messages were truly unordered and optional, we could
write it in this way:

     self layoutPolicy: TableLayout new
          listDirection: #leftToRight
          wrapCentering: #topLeft
          hResizing: #spaceFill
          vResizing: #spaceFill


and could make any order of these keywords to mean the same thing.
Then, the need for semi-colon can be alleviated.  Perhaps then, using
it for omitting a pair of parenthesis might be a reasonable thing to
do.  Or not.  For Transcript or the renderer in Seaside, these should
be ordered...

-- Yoshiki

On Wed, 29 Aug 2007 22:55:39 -0700, Yoshiki Ohshima  
<[hidden email]> wrote:

> if these keywords messages were truly unordered and optional, we could
> write it in this way:

This is the way my thinking runs, though there are issues (like the  
possibility of creating something that changing the order gives a  
deceptive clue to the semantic meaning). But say we have a method with  
three parms, we may end up with routines like so (ignore the punctuation  
here, I'm throwing out ideas that have come from my attempts at designing  
a language):

aMethod with: and: plus:

where the parameters are optional, we end up with routines like:

aMethod withParm1: aParm1
    aMethod with: aParm and: defaultParm2 plus: defaultParm3

aMethod withParm2: aParm2
    aMethod with: defaultParm1 and: aParm2 plus: defaultParm3

aMethod withParm1: aParm1 andParm3: aParm3
    aMethod with: defaultParm1 and: defaultParm2 plus: aParm3

versus a single method where optional parameters are noted in some fashion:

aMethod [with: aParm1] [and: aParm2] [plus: aParm3]
    aParm1 unassigned: defaultParm1.
    aParm2 unassigned: defaultParm2.
    aParm3 unassigned: defaultParm3.

Square brackets borrowed from grep to mean "optional parameter" with the  
unassigned method of course meaning "if not nil then assign this value".

And then there's and:and:and:and versus:

and: *block
    self ifFalse: [^false].
    block do: [value | ifFalse: [^false]].
    ^true.

which could be called the same way as "and:and:and:and:" only with no  
limit on the number of "and"s, and with only one method to do so.

And how about a keyword/keywords without parameters, i.e., values that  
have meaning just by being specified?

switch [on]

or select many/select one-type lists:

switch [on|off|flip]
fire [red,green,blue]

        These were ideas that I came up with while trying to make things even  
more "natural". I don't know all the ramigications of such changes  
(although it'd clean up the Boolean class), but these discussions have  
encouraged me to experiment.

On Wed, 29 Aug 2007 22:55:39 -0700, Yoshiki Ohshima  
<[hidden email]> wrote:

> Traits in Squeak really didn't turn out be as
> successful as it should have been, but that kind of change, for
> example.

They're too well hidden. I've been trying (off and on) to figure out how  
to see them for months now. I'm trying to figure out where they fit in  
pedagogically (teach them with objects? after objects? before, maybe  
even?).

On Aug 30, 2007, at 5:21 AM, Alan Kay wrote:

> But consider the Internet as a real object oriented system ...
>
> Cheers,
>
> Alan
>
> -------------
>

I knew that you would say that.
I wrote a sentence in a previous post: "but Alan Kay would consider  
this a step backward. Not a step forward". But than I said no, I'll  
not send that.

And I always had in mind your voice saying: "no no no: It's not what  
I have in mind."

on the other hand ....

On Aug 25, 2007, at 9:05 PM, Alan Kay wrote:
>
> And so would pipes. They provide a syntactical way of writing very  
> useful sequences of processing that is much nicer than functional  
> application syntax (which gives a difficult to read "backwards  
> view"), and Haskell did absolutely the right thing in making an  
> operator for this.

With objects AND the pipe we could have some of the qualities of an  
extensional system (features for free, less bloat) while keeping  
internet as real object oriented system (a rich system).
Some times a dumb object might be alright: for example when  
developing services, for instance when there is the need to talk with  
others (non-Smalltalk) as in real-life this happens.
Many times a rich object can do better: to get out rich media.

Do you see the pipe as useful or it is against object orientation ?  
It's not very clear to me what is your opinion on this matter, and it  
very important to me.

I think it's better to have it. At least I can have a choice. Rich  
object oriented system as often as possible. But practicality when  
practicality matters most.

Fabio