As best I can tell, it separates iteration ("stepping") from transformation, so that transformers can be applied more flexibly and be composed more easily.
This is certainly elegant but I'm not sure I'd want to work in a large codebase full of this kind of code. Sometimes it's easier to just see a loop spelled out in front of you. I'm a critic of Go in many ways but I do think there is something to their principle of keeping code very simple and readable and localized.
I think this is ok if you only use once, but as soon as you begin to use the same alorithm in multible places and contects you be happy with having it stored in one place.
In go you will have to replicate to logic every single time. I have not used much, but the fact that I cant even use generic map/filter things make me not want to try it. Even when I first learned programming (in C) I was trying to figure out how not to write for (int x=0;x==5;x++) again and again. I dont really want to go back to that.
I'm sure something said that about for loops vs goto some time ago :) Personally (which is important, readability is relative) I find for loops less readable than traditional FP functions like filter, any?, map, etc - I don't have to carefully read the entire for loop to know what's going on. I prefer composability of known pieces, over constructs that can do anything.
Much of the spec and the lib for the ruby version reads like it was written by a clojurist. That may sound funny, but it was all written by David Chelimsky, a long time rubyist who maintained RSpec.
To me the most interesting aspect of the Ruby implementation is the use of pseudo macros that meta-program most of the implementation.
Agreed, the code could be made a bit more idiomatic.
Introducing a Transducable module would also make sense in the OOP perspective. Replacing Transducer.transduce(transducer, ...) calls with transducer.transduce(...), same with Transducer.compose
[+] [-] anon45346536|11 years ago|reply
[+] [-] pavelrub|11 years ago|reply
[+] [-] augustl|11 years ago|reply
[+] [-] wcummings|11 years ago|reply
[+] [-] cageface|11 years ago|reply
[+] [-] nickik|11 years ago|reply
In go you will have to replicate to logic every single time. I have not used much, but the fact that I cant even use generic map/filter things make me not want to try it. Even when I first learned programming (in C) I was trying to figure out how not to write for (int x=0;x==5;x++) again and again. I dont really want to go back to that.
[+] [-] augustl|11 years ago|reply
[+] [-] pselbert|11 years ago|reply
To me the most interesting aspect of the Ruby implementation is the use of pseudo macros that meta-program most of the implementation.
[+] [-] zimbatm|11 years ago|reply
Introducing a Transducable module would also make sense in the OOP perspective. Replacing Transducer.transduce(transducer, ...) calls with transducer.transduce(...), same with Transducer.compose
[+] [-] jakestl|11 years ago|reply
[+] [-] kenko|11 years ago|reply