<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Aug 30, 2007, at 7:55 AM, Yoshiki Ohshima 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"><SPAN class="Apple-converted-space"> </SPAN>I don't see real benefit to change the language just to achieve a</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">very tiny, tiny subjective benefit at some corner cases.<SPAN class="Apple-converted-space"> </SPAN></FONT></P></BLOCKQUOTE><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">As many have pointed out, the unary messages or binary messages are already "piped"</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">(strange word, as they are just ordinally chained expressions after</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">all).<SPAN class="Apple-converted-space"> </SPAN>So, insisting that Smalltalk-80 lacks the concept is not simply</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">true.<SPAN class="Apple-converted-space"> </SPAN></FONT></P></BLOCKQUOTE><BLOCKQUOTE type="cite"><BR></BLOCKQUOTE><DIV>This is absolutely false.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Smalltalk-80 lacks the concept of EASY "pipes" (chained functional applications) </DIV><DIV>as it is evident from the difference between</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>(((obj method:param1) method:param2) method:param3)</DIV><DIV>and</DIV><DIV>obj method:param1 | method:param2 | method:param3.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Smalltalk does't have EASY chained message sends .</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>To the daily programmers life means: either you do </DIV><DIV> - collect:thenSelect: -> This is a big source of bloat...</DIV><DIV>or:</DIV><DIV> - ((obj collect:...) send: ...) -> well... this is simply ugly and difficult write while prototyping</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>no other way in Smalltalk.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Smalltalk is inconsistent too.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>obj send1 send2 send3.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A perfect pipe. Is it ? Too bad that you can do only it sometimes not when you want.</DIV><DIV>You can do it only if the method has no parameters.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This is a fact. No opinions. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It's inconsistent and easy chained functional applications are missing, and this has dramatic effects on the rest of the language.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><BLOCKQUOTE type="cite"><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"><SPAN class="Apple-converted-space"> </SPAN>Many proposed syntax for it in this thread are tiny syntax sugar,</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">and comes with a lot of unnecessary surprises.<SPAN class="Apple-converted-space"> </SPAN>(I like the clever</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">tricks and aesthetic sense people have shown, though.)</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I've shown how it's not just a syntax change. It will have a domino effect. It will change dramatically the whole language.</DIV><BR><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica"><SPAN class="Apple-converted-space"> </SPAN>BTW, to the eyes of a real functional programmer, the message</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">patterns connected with '|' looks like a pattern matching expression.</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">This will be another reason to say it is an unnecessary surprise.</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>BTW, to the real functional programmer, programming is about function selection and function application. </DIV><DIV>It just happens that the `|` is traditionally used to separate pattern matching. But other characters could be used and have been proposed.</DIV><DIV>To the eyes of a real functional what strikes most is the absence of an easy "function application" (not very precise thou, because smalltalk have objects and messaging)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><BLOCKQUOTE type="cite"> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica"><SPAN class="Apple-converted-space"> </SPAN>If we think about the magnitude of changes from Smalltalk-72 to</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Smalltalk-76 to Smalltalk-80, I hope the change to the language has</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">that kind of magnitude.<SPAN class="Apple-converted-space"> <BR></SPAN></FONT></P></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Putting the pipe will dramatically change the language. </DIV><DIV>It will become more functional, instead for more objective.</DIV><DIV>Objects will have some reasons to stay dumb instead of smart.</DIV><DIV>Long chains will start to appear and will replace the need for complex objects.</DIV><DIV>Economically the users in the long term will search for a `common` protocol to maximize the `get free combined functionality` effect.</DIV></DIV><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><DIV>Each point has examples, historical references and quantitative analysis. It's not just opinions of one guy.</DIV><DIV>Is what all the others are doing (unix, lisp, erlang, haskell, ocaml).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I like Smalltalk because the guys who did it got right that programming is for humans. The only a structure similar to a living organism can be able to deal with complexity. But at the same time they, in my humble opinion, they missed that humans - and this is important - think functionally. This is true today, was true in past, and will be true in the future.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And smalltalk IS good for functional programming but it needs this fix, if it want's to do the job really well.</DIV><DIV>But the community might say "we don't want that". </DIV><DIV>Or might say "make smalltalk more attractive to functional programmers".</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Putting the pipe is a HUGE change. It's like saying "Smalltalk is a functional programming language. By the way it's also an object oriented one".</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><DIV><DIV>On Aug 30, 2007, at 7:55 AM, Yoshiki Ohshima wrote:</DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">If one feels that he has to use many exclamation marks</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in a row or many capitalized words when he is supposed to convince</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">people logically, it is a "smell" of lack of deep logic.</DIV></BLOCKQUOTE></DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm writing in a discussion group. I'm not writing to publish a paper. I'll put as many exclamation marks I want, as many question marks I want and USE ALL THE CAPITALIZED WORDS I WANT. Or I mIgHt EvEn WriTe Like ThIs. Joking :-). But I do apologize for my writing skills, and will do better.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>But my arguments are clear, logical, supported by history references and examples.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm sure you can do the the hard work of ignoring the capitalized words and exclamation marks as many are doing, and focus a bit more on the message that I'm trying to convey.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Fabio Filasieno</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>