On Aug 27, 2007, at 10:07 PM, Jason Johnson wrote:
On 8/27/07, Fabio Filasieno fabio.filasieno@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