On Aug 27, 2007, at 10:07 PM, Jason Johnson wrote:

> On 8/27/07, Fabio Filasieno <fabio.filasieno at gmail.com> wrote:
>>
>> Long chains smells alright to me.
>
> Give it time.  Smalltalk has this amazing property that the code truly
> seems to "talk" to you and point out things that just aren't quite
> right.  Some parts of the code seem to "stick out".  You notice them
> every time you browse through your code.  And every time I have seen
> this so far, I found a nice refactoring that made the whole system
> less complex.

You are missing something... the pipe is very good for prototyping.  
You are not taking into account how easy is to bind existing  
functionality.

Just stick together things with glue (pipe) at the beginning. This  
way you are writing the spec !!!!!!

My experience tells me that this way of working produces results.
The code is done quick - and very readable ! - with lots of chains.  
Tests are written. Then some cleaning.

It's like doing sketches.

The way you do without the pipe is that you need to guess the right  
re-factoring without a "code as spec"
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.

When I was a bit younger I often made this mistake:

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 ...
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.

Maybe you can do it. But for me it works better to chain stuff to get  
the spec out and then clean if required.

The problem of writing complex systems like software is not building  
them, it's understanding what really needs to be done !!!!
Spec hunting is the problem ! No building the system !

For example.

if I have :

data select: ... | map: ... | collect: ...

I've written quickly a spec. And a very good one as it's WRITTEN down  
and it's TESTABLE.

Only then I might add
data searchForThis

But How do you know in advance you need that.

With functional programming you:
1) patch the functionally...
data select: ... | map: ... | collect: ...
2) test
... some unit tests

And there you go a system that works.

Now you can't tell me that  :
data select: ... | map: ... | collect: ...
this NOT understandable.... it's only a bit verbose... but since it's  
functional it's CLEAR

3) Now that you know you TRULY need ...
data select: ... | map: ... | collect: ...
you add
data searchForThis

And you've got also tests ready to go !!!!!!


> Give it time.  Smalltalk has this amazing property that the code truly
> seems to "talk" to you
>
Give it time. Functional programming has this amazing property that  
you can easily reason about problems, especially when side-effect free.

I want that in Smalltalk.
I can't do it with parenthesis. It disturbs me. I have to break my  
thoughts.
I need the pipe.

And I'm sure that any functional programmer (from ocaml, erlang ,  
haskell, ... ) would understand what I'm talking about.

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-dow approach that I use in system building, but to do the bottom- 
down properly... I need the pipe.

Fabio Filasieno




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