Pipe syntax and the current methods

Fabio Filasieno fabio.filasieno at gmail.com
Tue Aug 28 08:58:51 UTC 2007


On Aug 27, 2007, at 10:38 PM, Michael Lucas-Smith wrote:

> I wish more of Smalltalk were written with this approach in mind,  
> it'd scale without effort then.. and programmers wouldn't  
> accidently create memory explosion bottlenecks without trying.  
> Multiple select:, collect:, reject: calls on large data sets will  
> bring any image to its knees in seconds if more than one concurrent  
> user invokes the same sort of operation at once.
>
> The speed issue comes not from the time it takes to do one call of  
> this - but what happens when multiple processes try to do the same  
> thing (eg: multiple users hitting your server at once). And the  
> speed issue comes in not from computing CPU cycles, but from memory  
> allocation and garbage collection.
>
> If you start with a collection of 100,000 things, you do 4  
> operations on it - three collect:'s and a reject:.. you'll probably  
> be allocating 4 arrays of 100,000 slots. That's 1.2mb's of data  
> you've just allocated. Now get 10 users using the same function at  
> the same time and you've just made 12mb's of data. Scale it up a  
> little more elaborate chains of functions or more users and you  
> have serious scalability issues.


That is not the point !
Performance is for LATER !

example:

obj proc: param | proc:param | proc:param

1) simplicity: no need to learn packages or libraries, a kid can do  
it easily too, and that for me is important ! Smalltalk is also for  
kids right ?
2) good for your thoughts: I usually do : write a method call (put a  
pipe). Think. write another method call (put a pipe). Think some  
more. write yet another method call .... aaaaaaand put a dot. Done.


Personally I start with long chains.
Then I write some tests.
The I rewrite after measuring. The rewrite is easy because you have a  
high level specification written in front of you ! Easy to read. Easy  
to understand. Which says to you:

do this -> then do that -> then do this -> ... and then you are done.

The previous line is a simple SPEC !!!!
IF is required - by hard proof. measured stats !!!! - I'll change the  
long chain it to ...

doFirstPartQuick -> doSecondPartQuick.


I decided to go for Smalltalk for better prototyping not for speed.
I spend usually 40% design 40 testing% 20%dumb coding.
With Smalltalk my aspirations were to cut the first and second, which  
are big for me.
I can't comment on current methods. Since I'm new on smalltalk.
Not having the pipe slows me - at least me, but I think all of you  
functional programmers - on the design bit.

This is bad because prototyping is king here. The fastest the design  
bit, the better.

Small-talkers you are competing with:
Directly with
  - Ruby
  - Python
  - Erlang
Indirectly with
  - Ocaml
  - Haskell

Why should I choose Smalltalk ?

The Smalltalk community needs to understand what a non smalltalk  
users sees in smalltalk.
I can tell you what attracted me to smalltalk - part from Alan Kay's  
videos.
Smalltalk is like drawing with a pencil. Other languages feels like  
drawing with a CAD.
You need to use the pencil before using the CAD.
Since Pipes makes Smalltalk better at prototyping, Pipes gives me a  
sharper pencil.

Fabio Filasieno



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070828/3fc3ab6d/attachment.htm


More information about the Squeak-dev mailing list