<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:07 PM, Jason Johnson 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">On 8/27/07, Fabio Filasieno <<A href="mailto:fabio.filasieno@gmail.com">fabio.filasieno@gmail.com</A>> wrote:</FONT></P> <BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 10.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Long chains smells alright to me.</FONT></P> </BLOCKQUOTE><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">Give it time.<SPAN class="Apple-converted-space"> </SPAN>Smalltalk has this amazing property that the code truly</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">seems to "talk" to you and point out things that just aren't quite</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">right.<SPAN class="Apple-converted-space"> </SPAN>Some parts of the code seem to "stick out".<SPAN class="Apple-converted-space"> </SPAN>You notice them</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">every time you browse through your code.<SPAN class="Apple-converted-space"> </SPAN>And every time I have seen</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">this so far, I found a nice refactoring that made the whole system</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">less complex.</FONT></P> </BLOCKQUOTE></DIV><BR> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>You are missing something... the pipe is very good for prototyping. You are not taking into account how easy is to bind existing functionality.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Just stick together things with glue (pipe) at the beginning. This way you are writing the spec !!!!!!</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>My experience tells me that this way of working produces results.</DIV><DIV>The code is done quick - and very readable ! - with lots of chains. Tests are written. Then some cleaning.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It's like doing sketches.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The way you do without the pipe is that you need to guess the right re-factoring without a "code as spec"</DIV><DIV>in front of you. This is difficult. There is a high risk of developing functions that you don't need. This is on of the main critics OOP.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>When I was a bit younger I often made this mistake:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Lets a make a nice apple object. The nice apple must have the `eat` method of course. An apple that cannot be eaten is rally a terrible apple, is it? So let's invest some time in our apple `eat` method. But here is the mistake ...</DIV><DIV>you are writing code to make pies. You will never eat the apple directly. You have just spent brain and time budget on something useless: the `eat` method on the apple object. I bet this is the main reason for code bloat in OOP and Smalltalk too.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Maybe you can do it. But for me it works better to chain stuff to get the spec out and then clean if required.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The problem of writing complex systems like software is not building them, it's understanding what really needs to be done !!!!</DIV><DIV>Spec hunting is the problem ! No building the system !</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>For example.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>if I have :</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>data select: ... | map: ... | collect: ...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I've written quickly a spec. And a very good one as it's WRITTEN down and it's TESTABLE.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Only then I might add</DIV><DIV>data searchForThis</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>But How do you know in advance you need that.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>With functional programming you:</DIV><DIV>1) patch the functionally...</DIV><DIV>data select: ... | map: ... | collect: ...</DIV><DIV>2) test</DIV><DIV>... some unit tests</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And there you go a system that works.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Now you can't tell me that :</DIV><DIV>data select: ... | map: ... | collect: ...</DIV><DIV>this NOT understandable.... it's only a bit verbose... but since it's functional it's CLEAR</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>3) Now that you know you TRULY need ...</DIV><DIV>data select: ... | map: ... | collect: ...</DIV><DIV>you add</DIV><DIV>data searchForThis</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And you've got also tests ready to go !!!!!!</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Give it time. Smalltalk has this amazing property that the code truly</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">seems to "talk" to you</DIV></BLOCKQUOTE><BLOCKQUOTE type="cite"><BR class="khtml-block-placeholder"></BLOCKQUOTE><DIV>Give it time. Functional programming has this amazing property that you can easily reason about problems, especially when side-effect free. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I want that in Smalltalk.</DIV><DIV>I can't do it with parenthesis. It disturbs me. I have to break my thoughts.</DIV><DIV>I need the pipe.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And I'm sure that any functional programmer (from ocaml, erlang , haskell, ... ) would understand what I'm talking about.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It's just that I see this great opportunity for smalltalk that with a little fix people like me would appreciate Smalltalk more.</DIV><DIV>The messaging system allows me to blend perfectly the mixed bottom-up top-dow approach that I use in system building, but to do the bottom-down properly... I need the pipe.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Fabio Filasieno</DIV><DIV><BR class="khtml-block-placeholder"></DIV></SPAN><DIV><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>