<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Aug 27, 2007, at 10:38 PM, Michael Lucas-Smith wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">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.</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">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.</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">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.</FONT></P> </BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>That is not the point !</DIV><DIV>Performance is for LATER ! </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>example:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>obj proc: param | proc:param | proc:param</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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 ?</DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Personally I start with long chains. </DIV><DIV>Then I write some tests. </DIV><DIV>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:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>do this -> then do that -> then do this -> ... and then you are done.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The previous line is a simple SPEC !!!!</DIV><DIV>IF is required - by hard proof. measured stats !!!! - I'll change the long chain it to ...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>doFirstPartQuick -> doSecondPartQuick.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I decided to go for Smalltalk for better prototyping not for speed.</DIV><DIV>I spend usually 40% design 40 testing% 20%dumb coding. </DIV><DIV>With Smalltalk my aspirations were to cut the first and second, which are big for me.</DIV><DIV>I can't comment on current methods. Since I'm new on smalltalk. </DIV><DIV>Not having the pipe slows me - at least me, but I think all of you functional programmers - on the design bit.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This is bad because prototyping is king here. The fastest the design bit, the better.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Small-talkers you are competing with:</DIV><DIV>Directly with</DIV><DIV> - Ruby</DIV><DIV> - Python</DIV><DIV> - Erlang </DIV><DIV>Indirectly with</DIV><DIV> - Ocaml</DIV><DIV> - Haskell</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Why should I choose Smalltalk ?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The Smalltalk community needs to understand what a non smalltalk users sees in smalltalk.</DIV><DIV>I can tell you what attracted me to smalltalk - part from Alan Kay's videos.</DIV><DIV>Smalltalk is like drawing with a pencil. Other languages feels like drawing with a CAD.</DIV><DIV>You need to use the pencil before using the CAD.</DIV><DIV>Since Pipes makes Smalltalk better at prototyping, Pipes gives me a sharper pencil.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Fabio Filasieno</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR></BODY></HTML>